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Section  1 


INTRODUCTION 


PURPOSE 

The  purpose  of  the  NAVY  PROGRAM  MANAGER'S  GUIDE  is  to  assist  the 
manager  of  any  acquisition  program  by  (1)  outlining  the  system  acquisi¬ 
tion  process,  (2)  identifying  participants  and  describing  their  roles, 
(3)  describing  the  procedures  necessary  to  move  the  program  from  one 
milestone  to  the  next,  and  (4)  identifying  possible  pitfalls  along  the 
way.  Rather  than  telling  the  manager  how  to  do  his  job,  the  Guide 
focuses  on  what  has  to  be  addressed  and,  where  possible,  outlines  metho¬ 
dologies  and  strategies  and  directs  the  manager  to  specific  sources  for 
help.* 


SCOPE 

The  Guide  covers  the  Department  of  the  Navy  (DON)  system  acquisi¬ 
tion  process,  leaning  heavily  on  lessons  learned  in  past  acquisition 
programs.  It  is  not  a  detailed  description  of  the  specific  duties  of 
the  acquisition  manager  as  these  will  differ  with  each  program.  Nor  is 
it  to  serve  in  lieu  of  the  many  official  Department  of  Defense  (DOD), 
Secretary  of  the  Navy  (SECNAV),  Comptroller  of  the  Navy  (NAVCOMPT), 
Office  of  the  Chief  of  Naval  Operations  (OPNAV),  Marine  Corps,  Naval 
Material  Command  (NAVMAT)  and  Systems  Command  (SYSCOM)  directives  and 
instructions  governing  the  acquisition  process.  It  is  the  manager's 
obligation  to  familiarize  himself**  with  these  publications  and  other 
relevant  official  literature.  A  chart  of  relevant  NAVMAT  and  higher 
controlling  documents  is  provided  on  Figure  4-22,  Section  4. 

The  DOD  has,  by  policy,  reduced  the  number  of  major  systems  that 
require  top  level  management  and,  at  this  time,  there  are  fewer  than  25 
Navy  major  systems.  This  GUIDE,  while  modeled  on  the  well -documented 
major  systems  acquisition  process,  is  intended  to  be  equally  applicable 
to  less-than-major  systems.  The  manager  of  a  less-than-major  program 
will  have  to  carefully  determine  which  portions  of  the  relevant  instruc¬ 
tions  and  directives  are  applicable  to  his  program.  The  reader  will 
obtain  the  maximum  benefit  from  this  GUIDE  if  he  has  previously  read 
Office  of  Management  and  Budget  (0MB)  Circular  A-109,  DOD  Directive 


*  Although  both  the  title  arid  text  of  this  GUIDE  use  the  term 
"program  manager",  the  information  contained  herein  is  equally 
applicable  to  less-than-major  programs  led  by  a  project  man¬ 
ager.  The  term  program  manager  (PM!  is  used  throughout  the 
GUIDE  for  convenience. 

**  Navy  policy  strongly  encourages  the  selection  of  the  best 
person  available  for  a  program  management  position,  regardless 
of  that  person's  sex.  However,  to  avoid  awkward  grammatical 
constructions,  masculine  pronouns  are  used  throughout  the 
GUIDE. 
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(DODD)  5000.1,  DOD  Instruction  (DODI)  5000.2,  DODD  5000.3,  DODD  5000.39, 
SECNAV  Instruction  (SECNAVINST)  5000.1,  OPNAV  Instruction  (OPNAVINST) 
5000.42,  NAVMAT  Instruction  (NAVMATINST)  5000.22,  and  for  Marine  Corps 
Acquisitions,  Marine  Corps  Order  (MCO)  P5000.10.  Anyone  involved  in 
system  acquisition  for  the  Navy  or  Marine  Corps  must  be  conversant  with 
these  documents. 

While  this  GUIDE  is  an  introduction  and  ready  reference  to  the  Navy 
acquisition  process,  it  is  not  a  substitute  for  the  courses  in  project 
management  offered  by  the  Defense  Systems  Management  College  (DSMC),  the 
Naval  Material  Command  (NMC)  Career  Development  Institute  and  the  Fede¬ 
ral  Acquisition  Institute  (FAI).  These  courses,  as  well  as  the  course 
on  thel Planning,  Programming,  and  Budgeting  System  (PPBS)  offered  by 
DOD,  are  all  strongly  recommended. 


ORGANIZATION 

This  GUIDE  is  divided  into  four  sections:  Section  1  -  an  overview 
of  the  system  acquisition  process;  Section  2  -  a  summary  of  the  duties 
of  the  PM  and  available  PM  support;  Section  3  -  a  detailed  discussion  of 
the  acquisition  process;  and  Section  4  -  a  discussion  of  available 
management  tools  and  critical  topics  that  are  not  phase-specific. 

The  information  presented  in  the  first  and  third  sections  of  this 
GUIDE  is  organized  chronologically,  paralleling  the  multiphase  Navy 
acquisition  process.  Some  of  the  procedural  steps  and  areas  of  concern 
that  will  require  PM  attention  occur  in  more  than  one  phase;  therefore, 
certain  duplications  and  redundancies  have  been  allowed  to  remain  in  the 
text  in  order  to  assist  the  PM  in  planning  and  executing  his  program. 


BACKGROUND 

A  Single  Policy  for  all  Naval  Acquisitions 

The  DON  acquisition  policy  is  the  product  of  a  long  evolutionary 
process.  Neither  static  nor  rigid,  it  seeks  to  provide  a  flexible 
structure  for  the  acquisition  process.  The  most  important  documents 
shaping  current  acquisition  policy  are  DODD  5000.1  and  its  implementing 
instructions,  DODI  5000.2  and  DODI  5000.3.  DODD  5000.1  takes  a  common 
sense  approach,  emphasizing  tailoring,  flexibility,  and  concurrency  in 
order  to  provide  efficient  and  effective  system  acquisition  policy. 
Although  DODD  5000,1  strictly  applies  only  to  major  acquisitions,  which 
are  defined  as  those  systems  for  which  the  Secretary  of  Defense  (SECDEF) 
chooses  to  act  as  the  program  decision  authority  (PDA),  it  also  requires 
that  the  management  principles  and  objectives  in  that  directive  shall  be 
applied  to  the  acquisition  of  those  defense  systems  not  designated  as 
major. 

SECNAVINST  5000. 1  invokes  DODD  5000.1  and  DODI  5000.2  not  only  for 
major  programs  but  also,  where  specified,  for  nonmajor  programs  as  well. 
SECNAVINST  5000.1  also  specifies  that  programs  of  all  other  categories 
are  to  be  guided  by  its  principles.  Such  application,  however,  should 
be  tailored  to  each  acquisition  program  consistent  with  its  nature  and 


cost.  Figure  1-1  indicates  the  relationship  of  the  documents  that 
provide  the  foundation  for  the  acquisition  process. 


FIGURE  1-1.  Relationship  of  Acquisition  Documents. 


Generally,  DON  acquisition  policy  calls  for  a  program  initiation 
decision  to  be  made  by  the  proper  program  decision  authority  and  appro¬ 
val  for  program  start  to  be  integrated  with  the  PPBS.  At  each  subse¬ 
quent  major  milestone,  the  PM  is  required  to  prepare  the  required  mile¬ 
stone  review  documentation  (MRD),  and  to  have  it  reviewed  by  the  chain 
of  command  and  submitted  to  tne  PDA  for  final  approval.  The  PDA  docu¬ 
ments  his  approval  and  gives  instructions  for  program  direction  in  a 
decision  memorandum  that  marks  the  milestone. 


Acquisition  Categories  (ACATs) 

DON  programs  are  classified  by  ACATs  which  determine  the  level  of 
review,  the  PDA,  and  applicable  procedures.  Programs  are  assigned  an 
ACAT  when  first  authorized  based  to  its  estimated  cost,  criticality  and 
political  sensitivity.  A  program  may  be  redesignated  any  time  thereaf¬ 
ter,  consistent  with  the  policy  of  controlled  decentralization.  Docu¬ 
mentation  supporting  the  program  initiation  and  milestone  decisions 
include  appropriate  ACAT  recommendations. 


ACAT  I .  The  SECDEF  designates  those  systems  that  are  to  be  managed 
as  major  systems.  Normally,  this  is  done  when  the  new  start  is  autho¬ 
rized  in  the  Program  Decision  Memorandum  (PDM).  The  decision  to  desig¬ 
nate  any  system  as  major  may  be  based  upon:  (1)  development  risk,  urgen¬ 
cy  of  need,  or  other  items  of  interest  to  the  SECDEF;  (Z)  joint  acquisi- 
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tion  of  a  system  by  the  DOD  and  representatives  of  an-other  nation,  or 
by  two  or  more  DOD  Components;  (3)  the  estimated  funding  requirement 
(ACAT  I  thresholds  are  $200  million  (Fiscal  Year  { FY )  80  dollars)  in 
RDT&E  funds  or  $1  billion  (FY80  dollars)  in  procurement  (production) 
funds,  or  both)  and  (4)  significant  congressional  interest. 


ACAT  IIS.  A  program  is  a  candidate  for  ACAT  IIS  designation  by 
SECNAV,  if  (a)  the  total  costs  are  expected  to  exceed  $100M  for  RDT&E, 
and/or  $500M  for  procurement  (FY80  dollars);  or  (b)  if  it  is  of  special 
SECNAV  interest,  such  as  a  joint  Service  or  multinational  program; 
because  of  congressional  interest;  a  history  of  technical,  cost  and 
schedule  problems;  an  extraordinary  acquisition  strategy  and/or  risks; 
criticality  of  mission  need;  or  unusual  manpower  and/or  system  needs  or 
demands. 


ACAT  IIC.  Programs  for  which  the  CNO  is  the  PDA  are  designated 
ACAT  IIC.  Nominal  thresholds  for  ACAT  IIC  programs  are  $1 OOM  RDT&E  and 
$500M  procurement  (FY80  dollars),  however  programs  will  be  considered 
for  this  designation  on  an  individual  basis,  based  on  many  factors. 
ACAT  IIC  designations  are  made  by  the  Director,  Office  of  Naval  Program 
Planning  (0P-090),  based  on  Director,  Office  of  Research,  Development, 
Test  and  Evaluation  (OP-098)  recommendation. 


ACAT  III.  Programs  for  which  Deputy  Chiefs  of  Naval  Operations 
(DCNOsl  or  Directors  of  Major  Staff  Offices  (DMSOs)  are  PDAs  are  desig¬ 
nated  ACAT  III.  There  is  no  dollar  threshold  for  ACAT  III;  programs  are 
assigned  this  category  if  they  affect  military  characteristics  of  ships 
or  aircraft,  directly  affect  the  Navy's  combat  capability,  or  could  be 
expected  to  interact  with  the  enemy.  Examples  are  radars,  sonars, 
radios,  navigation  systems,  electronic  warfare  systems,  aircraft  opera¬ 
tional  flight  programs,  or  ordnance.  ACAT  III  applies  to  hardware  and 
software,  new  systems  and  modifications.  OP-098  designates  programs 
which  are  ACAT  III,  making  case-by-case  decisions  based  on  all  pertinent 
factors. 


ACAT  IV.  All  acquisition  programs  not  otherwise  designated  are 
ACAT  IV,  with  CNM  (or  his  designee)  as  the  designated  PDA.  Within  ACAT 
IV,  a  new  experimental  category,  ACAT  IVT,  has  been  established  by  0P- 
098,  in  an  attempt  to  achieve  greater  decentralization  of  decision 
making.  Other  ACAT  IV  programs  are  designated  ACAT  IVM.  The  distin¬ 
guishing  feature  on  ACAT  IVT  programs  (which  would  otherwise  be  ACAT 
III)  is  that  they  do  not  meet  the  new  criteria  for  ACAT  III  (described 
above),  but  they  do  require  operational  test  and  evaluation  (OT&E)  (a 
Commander,  Operational  Vest  and  Evaluation  Force  (COMOPTEVFOR)  responsi¬ 
bility).  Examples  are  a  swimmer  distress  signal  or  the  software  program 
for  a  flight  simulator.  In  ACAT  IVT  programs,  should  a  disagreement 
arise  between  COMOPTEVFOR  and  the  SYSCOM  commander,  the  issue  will  be 
referred  to  CNM.  ACAT  IVT  and  IVM  designations  are  made  by  OP-098. 

The  PM  should  be  aware  that  a  program  may  be  raised  or  downgraded 
in  significance  to  the  DON  and  the  DOD  so  that  its  level  of  approval  and 


ACAT  may  shift.  A  consideration  in  the  assignment  of  an  ACAT  will  be 
the  number  of  programs  already  receiving  SECDEF  or  SECNAV  review.  The 
number  of  programs  subject  to  such  high  levels  of  review  will  be  re¬ 
stricted. 

Figure  1-2,  on  the  next  page,  presents  the  foregoing  and  other 
information  on  the  Navy  ACATs  in  tabular  form. 

NOTE:  The  CNM  has  delegated  responsibility  for  ACAT  IV  pro¬ 
grams  to  the  SYSCOM  Commanders. 


OOP  Acquisition  Policy 

The  principal  thrusts  guiding  00D  acquisition  policy  include: 

1.  The  requirement  to  express  needs  in  mission  terms  and  not  equip¬ 
ment  terms. 

2.  The  requirement  for  agency  head  approval  at  key  decision  points 
(milestones) . 

3.  The  requirement  that  all  goods  and  services  be  acquired  on  a 
competitive  basis  to  the  maximum  extent  possible  in  order  to 
maximize  innovation  and  minimize  costs. 

4.  Consideration  of  life-cycle  cost  (LCC)  such  that  affordabili  ty 
is  put  on  an  equal  basis  with  system  performance,  schedule,  and 
logistic  supportability. 

5.  Establishment  of  clear  lines  of  authority,  responsibility,  and 
accountability  for  the  management  of  programs. 

NOTE:  At  the  direction  of  Congress,  DOD  is  establishing  the 
office  of  the  Director  of  Operational  Test  and  Evaluation. 

That  office  will  be  responsible  for  reviewing,  for  all  ACAT  I 
programs,  the  Test  and  Evaluation  Master  Plan  (TEMP)  and  the 
operational  test  and  evaluation  results  prior  to  each  mile¬ 
stone  decision. 


DON  Acquisition  Policy 

DON  acquisition  policy  is  based  upon  the  principles  applied  in  past 
successful  projects  and  on  experience  gained  in  past  unsuccessful  pro¬ 
jects.  Emphasis  is  on  defining  the  problem  to  be  solved  in  terms  of 
mission  need,  and  tailoring  the  extent  and  rigor  of  the  investigation  of 
alternative  solutions  to  the  stated  problem  according  to  the  specific 
need.  In  contrast  with  previous  practice,  the  proposers  of  alternative 
concepts  have  much  greater  latitude  in  the  approach  they  take  in  solving 
the  problem  posed  in  the  program  initiation  document. 

The  DON  also  fully  subscribes  to  the  recent  acquisition  management 
initiatives  of  DOD  to  curb  cost-growth  trends.  These  initiatives  are 
designed  to  enhance  program  stability,  delegate  authority  for  weapon 
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(1)  -  The  SCP/OCP/NDCP/TEM?  review  and  approval  process  precedes  the 

actual  milestone  review,  decision  end  approval  process. 

(2)  -  OP-06  for  strategic  nuclear  systems. 

(3)  -  Milestone  111  decision  authority  Is  normally  delegated  to  the  SEC- 

NAV  unless  thresholds,  established  at  Hllestone  11,  are  breached. 
U)  -  An  IPS  may  be  required  when  the  OAE  determines  that  the  DCP  lacks 
sufficient  Information  on  which  to  base  a  milestone  decision. 

(5)  -  Milestone  I  Is  normally  eliminated. 

-  All  TEMPs  must  also  be  approved  by  COMOPTEVFOR. 

-  See  list  of  Abbreviations  on  facing  page, 
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Acquisition  Category 
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Decision  Coordinating  Paper 

Department  of  the  Navy  Systems  Acquisition  Review  Council 
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System  Command  Commander 
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FIGURE  1-2,  Acquisition  Categories  (ACATs). 
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systems  program  management,  achieve  more  economical  rates  of  production, 
and  attain  realistic  costing  and  budgeting  for  weapon  systems.  Other 
significant  changes  from  past  policy  are  the  increased  emphasis  on 
affordability,  competition,  system  readiness  and  sustainability,  pre¬ 
planned  product  improvement  (P3I),  and  incorporation  of  initial  program 
approval  into  the  PPBS. 


Mission  Need  Versus  Technology  as  System  Drivers 

In  the  1970s,  system  acquisition  programs  were  usually  focused  on 
specific  technical  approaches  at  the  time  of  their  initiation.  These 
programs  might  be  carried  well  into  the  advanced  development  stages 
before  alternatives  for  fulfilling  the  mission  need  had  been  considered. 
In  addition,  the  total  development,  production,  and  support  cost  of  of  a 
particular  technical  approach  (LCC)  often  was  not  considered  in  the 
initial  stages  of  the  acquisition  process,  and  by  the  time  the  prohibi¬ 
tive  cost  of  deployment  was  revealed,  enormous  amounts  of  time  and  money 
had  been  expended.  Today,  a  program  is  initiated  after  competent  autho¬ 
rity,  the  PDA,  approves  a  specific,  formally  stated  mission  need,  based 
on  MAA,  submitted  within  the  first  Program  Objectives  Memorandum  (POM) 
in  which  program  funds  are  requested. 


Flexibility 

The  current  system  provides  for  and  encourages  flexibility  in  the 
acquisition  process.  Each  program  should  be  evaluated  separately,  and 
the  acquisition  strategy  should  be  tailored  to  best  reconcile  technolo¬ 
gical  risk,  development  time,  and  cost.  There  are  several  points  at 
which  the  PM  may  shorten  phases  or  bypass  them  altogether.  The  PDA  may 
approve  elimination  of  the  Concept  Exploration  and  Demonstration  and 
Validation  Phases,  authorize  development  of  a  non-competitive  (single¬ 
concept)  system,  and  increase  the  degree  of  concurrency  if  these  steps 
are  justified  by  urgency  of  need  or  by  the  demonstrated  maturity  of  the 
selected  concept.  In  all  cases,  it  is  the  PM  who  must  take  the  initia¬ 
tive  of  shaping  the  program  to  give  it  the  flexibility  that  the  acquisi¬ 
tion  process  permits  and  encourages. 


Costs  and  Schedule 

Regardless  of  the  magnitude  of  the  program,  DON  policy  requires  a 
continuing  effort  to  reduce  and  control  the  costs  of  new  system  acquisi¬ 
tions  and  to  shorten  the  time  between  program  initiation  and  fielding  of 
the  needed  systems.  While  it  is  recognized  that  the  PM's  concern  is 
often  fixed  on  development  costs,  increasingly,  concern  at  higher  levels 
and  in  Congress  is  on  life-cycle  costs.  As  a  result,  it  is  often 
possible  to  justify  increased  development  cost  if  savings  can  be  made 
later  in  reduced  production  and/or  operational  expenses. 

Alternatives  to  a  New  Start.  Before  a  new  start  is  initiated,  al¬ 
ternatives  that  are  evolutionary  and  low  risk  must  be  examined.  The 
need  may  be  filled  by  changes  in  doctrine  or  tactics,  or  by  an  adjust¬ 
ment  in  the  level  or  mix  of  forces.  Existing  equipment  may  be  altered 


or  upgraded  to  fill  the  need,  or  foreign  equipment  may  do  the  job.  A 
new  development  is  in  fact  the  least  attractive  alternative  available 
because  of  its  intrinsic  cost-schedule-performance-supportability  uncer¬ 
tainties.  However,  the  CNO  has  stated  that  we  cannot  be  overly  reliant 
on  risk-avoidance  approaches  when  the  risk  of  technical  surprise  from  a 
rapidly  modernizing  threat  is  growing. 

Relationship  of  Development  Cost  in  System  Life-Cycle  Cost  (LCC). 
From  a  program' s  outset,  LCC  -  total  cost  to  the  government  of  acquisi- 
tion  and  ownership  of  a  system  over  its  full  life,  including  cost  of 
development,  procurement,  operation,  support,  and  where  applicable, 
disposal  -  must  be  considered  on  an  equal  footing  with  performance,  time 
and  logistic  supportabi 1 ity  constraints.  Decisions  made  very  early  in  a 
program  determine  the  costs  throughout  the  life  of  the  system.  This 
fact  is  graphically  illustrated  in  Figure  1-3.  Note  that  decisions  made 
during  the  Concept  Exploration  Phase  (especially  the  decisions  as  to 
which  concept  is  selected  and  what  the  performance  thresholds  are)  fix 
approximately  70%  of  the  LCC.  Roughly  85%  of  the  LCC  are  frozen  before 
the  Full-Scale  Development  Phase  begins,  when  only  a  small  percentage  of 
the  total  system  cost  has  been  expended.  A  little  more  money  spent  in 
the  early  stages  of  the  program  can  save  a  great  deal  of  money  over  the 
life  of  the  system. 

Because  of  the  effect  that  the  chosen  concept  has  on  the  LCC,  a 
broad  solicitation  of  concepts  from  the  civilian  sector  and  Navy  in- 
house  activities  is  required.  This  competitive  approach  provides  a  wide 
range  of  concepts  from  which  to  select  the  most  feasible  means  of  ful¬ 
filling  the  mission  need  and,  at  the  same  time,  provides  alternative 
performance  levels,  schedules,  and  cost  estimates  with  which  to  make 
performance/cost/time  trade-offs . 


SYSTEM  LIFE  CYCLE,  DSARC  MILESTONES 


FIGURE  1-3.  Typical  Weapon  System  Life-Cycle  Cost  (LCC). 
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Realistic  Costing  and  Budgeting.  Large  growth  in  costs  during  a 
system7"!  development  and  operation  seriously  undermines  both  the  Con¬ 
gress'  and  public's  faith  in  the  Navy  and  DOD.  Such  cost  growth  signi¬ 
ficantly  impairs  the  Navy's  ability  to  budget  for  the  necessary  quanti¬ 
ties  and  typos  of  weapon  systems. 

The  PM  must  ensure  that  only  realistic  cost  and  budget  information 
is  provided  and  that  such  information  is  accurate  and  complete.  Cost 
estimates  must  include  the  full  anticipated  development,  production,  and 
operational  costs  associated  with  the  program,  even  though  this  task  is 
especially  difficult  at  program  initiation.  The  estimates  will  include 
budgeting  and  early  funding  for  testing  (including  adequate  numbers  of 
test  items,  special  test  equipment,  and  facilities),  budgeting  for  most- 
likely  costs  {including  inflation),  budgeting  for  technical  and  schedul¬ 
ing  risks,  capitalization  of  production  and  specialized  operational 
facilities,  and  independent  cost  analysis. 


Reliability,  Readiness  and  Logistic  Supportability 

As  indicated  in  Figure  1-3,  operation  and  support  costs  of  a  system 
often  account  for  50  to  60%  of  the  total  LCC.  Significant  savings  can 
be  achieved  through  investments  early  in  the  program  that  will  increase 
system  reliability  and  simplify  maintenance.  Reliability  and  logistic 
supportability  are  design  attributes,  and  improving  them  will  markedly 
increase  system  readiness.  DODD  5000.1  and  DODD  5000.39  require  that 
acquisition  programs  shall  have  an  integrated  logistic  support  (ILS) 
program  that  begins  at  program  initiation  and  that  readiness  objectives 
and  related  design  requirements/activities  be  established  early  in  the 
acquisition  process,  specifically  in  the  acquisition  strategy,  and  that 
they  receive  comparable  emphasis  with  cost,  schedule  and  performance 
objectives. 


Competition 

The  DON  acquisition  policy  recognizes  that  competition  encourages 
innovation  and  efficiency,  providing  quality  products  at  the  lowest 
possible  price;  and  the  requirement  to  seek  competition  is  a  continuing 
legal  obligation,  not  just  a  platitude  periodically  dusted  off  for 
seminars  and  conferences.  How  much  competition,  how  long  such  competi¬ 
tion  should  be  maintained  in  the  development  process,  and  at  what  cost 
are  issues  that  must  be  determined  independently  for  each  program.  The 
PM  must  determine  how  and  to  what  level  (system,  subsystem,  component) 
to  develop  and  maintain  beneficial  competition.  If  it  is  desirable  to 
maintain  competition  through  the  production  stage,  he  must  ensure  that 
adequate  documentation  is  produced  during  the  development  stage.  Compe¬ 
tition  is  one  of  the  key  elements  to  bo  addressed  in  the  acquisition 
strategy. 


Competition  in  Contracting  Act  of  1984  (CICA) 

Implementation  of  the  CICA  is  a  major  endeaver  including  sustantial 
revision  of  the  Federal  Acquisition  Regulations  (FAR)  and  the  DOD 
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Federal  Acquisition  Regulations  Supplement  (DFARS).  The  major  thrust  of 
C1CA  is  establishment  of  full  and  open  competition  as  the  standard  in 
government  contacting.  In  so  doing,  the  statutory  distinction  between 
formal  advertising  and  negotiation  is  removed  eliminating  the  need  for 
Determinations  and  Findings  (D&Fs)  to  support  negotiated  procurements. 
The  term  "sealed  bid"  replaces  the  term  "formally  advertised"  but  the 
related  solicitation  and  bid  procedures  remain  the  same.  Sealed  bids 
will  be  used  when  appropriate  conditions  exist. 

Competition  requirements  are  being  consolidated  and  published  in  a 
new  Part  6  of  the  FAR.  There  will  be  7  specific  exceptions  to  the  use 
of  full  and  open  competition.  When  use  of  other  than  full  and  open 
competition  is  contemplated,  a  detailed  justification  must  be  submitted 
for  approval  by  the  appropriate  authority  depending  upon  the  estimated 
dollar  amount  of  the  procurement  as  follows: 

$100,000  to  $1M  -  procuring  activity  Competition  Advocate 

$1M  to  $10M  -  head  of  the  contracting  activity  or  flag/SES 

delegate 

Over  $10M  -  Navy  Senior  Procurement  Executive  (NSPE) 

The  NSPE  is  the  Assistant  Secretary  of  the  Navy,  Shipbuilding  and 
Logistics  [ASN(S&L)].  For  those  actions  requiring  NSPE  approval,  an 
approved  Acquisition  Plan  (AP),  as  required  by  FAR  Part  7,  must  be 
submitted  along  with  the  justification. 

CICA  and  the  related  regulation  changes  will  apply  to  all  solicita¬ 
tions  issued  on  or  after  1  April  1985. 


Key  Decision  Points 


An  important  feature  of  the  present  acquisition  policy  is  the 
reservation  of  final  review  and  key  decision-making  to  SECDEF  for  major 
programs  and  to  appropriate  decision  authorities  for  les;,-than-major 
programs.  This  feature  is  intended  to  ensure  that  the  proper  level  of 
review  is  made  prior  to  the  commitment  of  major  resources  and  that 
efforts  to  meet  the  stated  mission  need  are  being  pursued  within  the 
bounds  of  current  acquisition  policy.  Review  is  also  conducted  at 
various  levels  between  the  PM  and  SECDEF  or  other  designated  PDA,  with 
the  highest  review  group  -  the  Defense  Systems  Acquisition  Review  Coun¬ 
cil  (DSARC)  -  giving  advisory  support  to  SECDEF. 


Streamlined  Procurement  Approach 

A  single  solicitation  calling  for  several  follow-on  proposals  may 
serve  the  procurement  needs  of  the  entire  program.  Procurement  is  also 
facilitated  by  the  requirement  to  minimize  detail  in  the  documentation. 
Initially,  the  required  documentation  describes  the  mission  need  and 
constraints  only  (e.g.,  ability  to  interface  with  certain  other  systems) 
and  avoids  specific  solutions  and  detailed  specifications.  The  documen¬ 
tation  is  then  refined  as  the  program  progresses  through  the  acquisition 
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phases.  At  the  end  of  the  Full-Scale  Development  Phase,  the  documenta¬ 
tion  is  complete  and  is  sufficiently  detailed  to  support  the  full-scale 
production  effort,  deployment  and  operation. 


Preplanned  Product  Improvement  ( P3 I ) 

The  time  from  inception  of  a  system  to  initial  operational  capa¬ 
bility  (IOC)  is  often  inordinately  long,  because  of  the  approval  process, 
single-year  funding,  the  increasing  complexity  of  modern  systems,  and  a 
desire  on  the  part  of  system  designers  and  sponsors  to  develop  an  end 
product  that  will  do  everything.  However,  a  system  that  will  fulfill 
90%  or  more  of  the  mission  goals  can  often  be  designed  in  far  less  than 
90%  of  the  time  necessary  to  achieve  all  of  the  goals.  A  P3I  plan 
facilitates  the  trade-off  between  time  and  performance  and  allows  ear¬ 
lier  Fleet  introduction  of  needed  capabilities  and  reduces  program  risk. 

P3I  is  an  acquisition  concept  that  encourages  orderly,  time-phased 
introduction  of  incremental  system  capability.  P3I  can  accommodate 
projected  changes  in  threat  or  reduce  the  risk  inherent  in  fielding  a 
system  that  is  dependent  on  unproven  technology.  The  concept  involves 
programming  resources  to  accomplish  orderly  and  cost-effective  evolution 
of  a  system's  capability,  utility,  and  operational  readiness.  As  well 
as  minimizing  the  technical  risk  of  fielding  a  system,  P3I  reduces  the 
potential  for  delayed  Fleet  introduction  that  is  posed  by  using  new 
technology  to  meet  a  military  threat. 

When  P3I  is  incorporated  in  the  acquisition  strategy,  some  poten¬ 
tial  initial  capability  of  the  system  may  be  sacrificed  to  obtain  a 
meaningful  improvement  in  Fleet  capability  in  a  much  shorter  time  than 
would  otherwise  be  possible.  Successive  improvements  in  the  system  are 
made  on  a  planned  basis  after  the  IOC  date. 

If  P3I  is  to  receive  adequate  consideration  during  the  system 
acquisition  process,  PMs  must  ensure  that: 

1.  System  need  documents  include  stepped  requirement,  performance, 
and  readiness  increases  and  list  growth  potential  as  a  high-priority 
characteristic. 

2.  P3I  is  placed  in  the  acquisition  strategy  and  detailed  in  the 
program  management  document  schedules  ana  resources  computations. 

3.  Growth  requirements  are  transited  into  design  criteria  that  are 
substantiated  through  development  testing. 

4.  Incentives  are  provided  in  the  development  contract  for  the 
achievement  of  growth  provisions. 

5.  P3I  modifications  are  scheduled,  programmed,  budgeted,  and  plan¬ 
ned  for  Fleet  introduction  with  the  same  attention  to  detail  as  the 
basic  system.  The  resources  to  accomplish  P3I  should  be  identified  by 
the  PM  for  inclusion  in  the  PPBS  cycle  and  placed  in  the  POM,  The  Five- 
Year  Defense  Program  (FYDP),  and  the  Extended  Planning  Annex  (EPA). 
Once  P3I  becomes  a  part  of  the  acquisition  strategy,  failure  to  fund  it 


will  be  considered  a  major  change  in  program  direction. 

Besides  shortening  the  inception-to-IOC  time,  P3I  may  tend  to  make 
PMs  and  sponsors  more  receptive  to  criticism  of  system  shortcomings  and 
thus  promote  a  more  open  relationship  with  Congress.  By  planning  the 
growth  from  the  initial  design  stages,  P3I  permits  development  of  a 
system  that  is  receptive  to  modification  in  response  to  downstream 
threat-definition  changes  and  future  technology  development. 


Product  Improvement 

The  modification  and  improvement  of  systems  which  have  been  devel¬ 
oped  without  P  I  is  often  necessary.  This  is  often  the  least  expensive 
and  most  rapid  means  for  meeting  new  Fleet  needs.  Deficiencies  may  be 
uncovered  during  fleet  use  that  not  even  the  best  engineering  could  have 
predicted  or  evaluation  programs  discovered.  A  strong  follow-on  engin¬ 
eering  effor  may  be  entered  into  with  the  objective  of  eliminating 
lingering  deficiencies,  enhancing  producibility,  and  realizing  the  full 
potential  of  the  system.  Current  congressional  sentiment  is  not  to  fund 
simultaneous  production  and  product  improvement  effort. 


THE  ACQUISITION  PROCESS 

The  DON'S  system  acquisition  process  normally  consists  of  four 
phases  which  are  separated  by  decision  milestones  as  shown  in  Figure  1- 
4.  The  phases  are  tailored  to  fit  each  program's  specific  requirements 
to  minimize  acquisition  time  and  cost,  consistent  with  the  need  and  the 
degree  of  technical  risk.  The  decision  milestones  are  adjusted  to  match 
the  selected  acquisition  strategy. 

The  acquisition  process,  though  conceptually  simple,  is  detailed  in 
its  requirements.  As  indicated  in  Figure  1-5,  ship  design/development 
milestones  are  somewhat  different  than  the  milestone  characteristic  of  a 
typical  weapon  system  acquisition. What  follows  provides  an  overview  of 
the  process,  concentrating  on  the  logical  interrelationship  of  the 
milestones  and  phases  and  deferring  to  Section  3  a  more  extensive  des¬ 
cription  of  each  milestone  and  phase  activities. 


Program  Origins,  Mission  Area  Analysis  (MAA) 

The  starting  point  of  the  acquisition  process  cannot  be  pinpointed. 
It  emerges  gradually  from  the  naval  operational  experience,  advances  in 
the  technology  base,  and  intelligence  assessment  of  the  threat  -  all 
integrated  through  onging  MAA.  During  this  process,  a  need  is  perceived 
in  a  particular  mission  area.  The  need  may  arise  from  a  changed  threat, 
projected  obsolescence  of  existing  systems,  technological  opportunity, 
or  a  cost-reduction  opportunity.  The  DON  will  evaluate  the  need  in 
light  of  other  needs,  existing  capabilities,  priorities,  and  resources, 
and  if  warranted,  prepare  a  requirements  document  describing  the  mission 
need. 


1-12 


ri 


fa 


k 


JkJL 


MISSION  NEED 
VALUATION 
_ RECONCILE 


RESOURCES  PRIORITIES 


xL 


MILESTONES 


PRODUCTION 

CONCEPT 

DEPLOYMENT 

EXPLORATION 

PHASE 

PHASE 

PULL  SCALE 

DEMONSTRATION 

DEVELOPMENT 

AND  VALIDATION 

PHASE 

PHASE 

T 


FIGURE  1-4.  Acquisition  Phases  and  Milestones. 


Phase 

Event 

Authori zed 
at  milestone 

Ship  acquisition  (design, 
development  for  operational 
use)  normally  ACAT  I 
or  IIS 

Ship  development  (design 
&  construction  for  research, 
test  or  evaluation)  normally 

ACAT  IIS  or  lower 

• 

Program 
lniti ation 

Conceptual  design  and 
trade-offs 

Conceptual  design  and 
trade-offs 

I 

Start  preliminary  design; 
preliminary  contract  design 

Start  preliminary  design 

» 

II 

Decision  for  lead  ship 
design  and  construction 

Contract  design  and  decision 
to  build 

III 

Design  for  follow-on  ships 

FIGURE  1-5.  Ship  Design/Development  Milestones. 


Program  Initiation 


Program  initiation  is  accomplished  as  part  of  the  PPBS  process 
based  upon  the  mission  need  document,  a  Justification  for  Major  system 
New  Start  (JMSNS)  or  an  Operational  Requirement  (OR).  This  document  is 
normally  submitted  during  the  POM  preparation,  review  and  approval 
process  for  the  budget  year  in  which  funds  are  requested.  The  PDA 
provides  appropriate  program  guidance  after  such  review.  This  action 
provides  official  sanction  for  a  new  program  start  and  authorizes,  when 
funds  are  available,  the  initiation  of  the  initial  acquisition  phase. 
Depending  upon  the  circumstances,  approval  may  be  given  to  omit  one  or 
more  of  the  following  phases. 


Concept  Exploration  Phase 

During  the  Concept  Exploration  Phase,  the  PM  will  solicit  and 
evaluate  alternative  concepts  that  will  meet  or  exceed  the  thresholds  of 
the  approved  need  document.  This  will  be  accomplished  in  cooperation 
with  industry,  in-house  Navy  Research  and  Development  ( R&D )  laborato¬ 
ries/centers,  universities,  and  federal  contract  research  centers 
(FCRCs),  all  of  which  are  equally  acceptable  concept  sources.  Candidate 
concepts  will  be  presented  along  with  estimates  of  their  LCC,  devel¬ 
opment  schedule,  and  performance.  Candidate  concepts  in  the  form  of 
technical  feasibility  models  may  be  subjected  to  development  test  and 
evaluation  ( DT&E )  and  initial  operational  test  and  evaluation  (I0T&E). 
The  PM,  in  part  through  the  use  of  independent  cost  and  technological 
analysis,  will  evaluate  the  alternative  concepts  and  recommend  one  or 
more  for  continuation  into  the  Demonstration  and  Validation  Phase. 

The  results  of  the  Concept  Exploration  Phase  are  documented,  and 
the  results  and  issues  are  discussed  in  the  milestone  review  documenta¬ 
tion  (MRD)  prepared  by  the  PM. 


Milestone  I 

The  first  major  milestone  decision  is  concept  selection  and  appro¬ 
val  to  enter  the  Demonstration  and  Validation  (D&V)  Phase.  This  deci¬ 
sion  is  a  validation  of  the  requirement,  based  upon  preliminary  evalua¬ 
tion  of  alternative  concepts,  costs,  schedule,  readiness  objectives  and 
affordability.  It  provides  authority  to  develop  the  conceptual  sys- 
tem(s)  sufficiently  to  support  the  next  milestone  decision.  The  Mile¬ 
stone  I  decision  establishes  thresholds  and  objectives  to  be  met  and 
reviewed  at  the  next  milestone,  the  acquisition  strategy  for  the  program 
(including  the  nature  and  timing  of  the  next  decision  point),  and  a 
dollar  threshold  that  cannot  be  exceeded  to  carry  the  program  through 
the  next  milestone.  NOTE:  For  ACAT  III  and  IV  programs.  Milestone  I 
may  be  eliminated  on  approval  of  the  acquisition  executive. 


Demonstration  and  Validation  (D&V)  Phase 


The  key  to  a  successful  D&V  Phase  's  a  well  thought-out  design 
effort.  Industry,  R&D  center  and/or  federal  contract  research  center 


(FCRC)  advanced  development  models  (ADMs ) /functional  breadboards  are 
fabricated  to  demonstrate  and  validate  the  critical  technical  and  opera¬ 
tional  features  of  the  selected  concepts.  This  involves  demonstration 
of  the  system  or  critical  subsystems  to  verify  performance,  ascertain 
the  potential  suitability  of  a  concept  to  fill  the  mission  need,  and 
establish  a  credible  baseline  LCC  estimate.  The  results  of  the  D&V 
Phase  (which  may  include  (OT&E)  will  be  documented  in  MRD  prepared  by 
the  PM. 


Milestone  II 


The  D&V  Phase  MRD  is  briefed  and  reviewed  as  appropriate.  The 
timing  of  the  Milestone  II  decision  is  flexible  and  depends  upon  the 
tailored  acquisition  strategy  approved  by  the  PDA  at  Milestone  I. 


Full-Scale  Development  (FSD)  Phase 


The  goal  of  the  FSD  Phase  is  to  produce  a  fully  tested,  documented, 
and  production-engineered  design  of  the  concept  selected  in  the  D&V 
Phase.  This  design  must  be  cost-effective,  operationally  suitable,  and 
producible.  It  is  developed  through  an  iterative  process  of  design- 
tesc-redesign.  The  final  product  is  a  baseline  configuration  design  and 
documentation  package.  The  development  effort  normally  proceeds  through 
three  distinct  subphases,  each  of  which  has  an  integral  testing  and 
evaluation  element. 

During  the  engineering  subphase,  the  engineering  rendition  of  the 
selected  technical  approaches  will  be  evolved  in  the  form  of  engineering 
development  models  (EDMs)/brassboards,  and  will  be  tested  and  evaluated 
prior  to  a  critical  design  review  (CDR).  A  considerable  saving  may  be 
afforded  by  using  simulations  and  laboratory  testing  before  going  to  the 
field  for  expensive  testing  and  evaluation. 

In  the  prototype  subphase,  preproduction  prototype  models  ( PPMs }  of 
the  engineered  designs  will  be  constructed,  tested,  evaluated,  and 
corrected  as  necessary  to  evolve  a  cost-effective  physical  and  function¬ 
al  equivalent  of  the  system  to  be  produced  in  the  subsequent  pilot- 
production  subphase.  Models  fabricated  during  the  last  part  of  the 
prototype  subphase  will  be  used  to  conduct  a  formal  technical  evaluation 
(TECHEVAL)  in  order  to  determine  and  certify  readiness  for  formal  opera¬ 
tional  evaluation  (OPEVAL). 

In  the  pilot-production/transition  to  production  subphase,  the  data 
package  that  was  evolved  and  evaluated  in  the  preceding  prototype  sub¬ 
phase  will  be  exercised  in  the  production  environment.  The  system  will 
be  fabricated  with  production  tools  and  test  equipment,  using  production 
processes,  procedures,  and  inspection  techniques.  The  first  units  de¬ 
rived  from  this  effort  will  be  evaluated  for  any  degradation  resulting 
from  the  production  process.  The  remaining  units  will  provide  the  test 
articles  required  for  OPEVAL,  leading  to  final  determination  of  opera¬ 
tional  effectiveness  and  operational  suitability  that  is  required  for 
approval  for  full  production  (AFP)  and  support  of  the  major  production 
decision,  Milestone  III.  Any  remaining  units  will  be  used  along  with 


those  from  the  Production  and  Deployment  Phase  to  provide  for  the  IOC. 
As  in  the  previous  phases,  the  results  of  the  FSD  Phase,  and  discussion 
of  these  results  and  issues  are  documented  by  the  PM  in  the  MRD. 


Milestone  III 

The  MRD  is  reviewed  as  appropriate  and  the  PDA's  decisions  are 
documented  in  a  new  decision  memorandum.  When  signed  by  the  PDA,  the 
decision  memorandum  authorizes  the  PM  to  proceed  with  the  Production  and 
Deployment  Phase.  In  certain  cases  the  PDA  may  delegate  the  Milestone 
III  decision  to  the  lowest  level  in  the  organization  at  which  a  compre¬ 
hensive  view  of  the  program  rests.  Normally  the  Milestone  III  decision 
for  a  DOD  Major  program  is  delegated,  by  the  SECDEF,  to  the  SECNAV 
unless  the  thresholds  established  at  Milestone  II  are  breached. 


Production  and  Deployment  Phase 

During  this  phase,  the  development  activity  will  proceed  with  the 
planned  procurement  program  and  introduce  the  system  into  the  Fleet. 
The  DON  will  normally  proceed  with  the  first  volume  production  by  con¬ 
tracting  with  the  development  contractor,  depending  on  the  approved 
acquisition  strategy.  For  high-volume  production  systems  where  com¬ 
petitive  procurement  can  be  justified,  early  actions  should  have  been 
taken  in  the  previous  phases  to  qualify  an  alternative  or  second  source. 
Follow-on  operational  test  and  evaluation  (FOT&E)  and  user  data  are 
necessary  elements  for  verifying  correction  of  any  deficiencies  noted  in 
GPEVAl  and  for  continued  product  improvement  and  tactics  development. 

Low-volume,  highly  sophisticated  systems  that  require  high-value 
facilities,  tools,  test  equipment,  and  an  inordinately  long  lead  time 
may  not  be  amendable  to  competitive  procurement.  The  decision  on  wheth¬ 
er  to  have  competitive  procurement  must  be  determined  on  an  individual 
basis  for  each  program.  It  should  be  made  only  after  a  detailed  cost- 
benefit  analysis  and  determination  of  the  level  of  mobilizction  require¬ 
ments.  Even  if  the  analysis  indicates  that  competitive  system  acquisi¬ 
tion  is  not  supportable  it  may  be  desirable  to  acquire  subsystems  or 
components  on  a  competitive  basis,  especially  if  the  same  subsystems  or 
components  are  used  in  other  systems.  The  necessary  preparations  will 
have  had  to  be  made  prior  to  or  at  the  beginning  of  the  Full-Scale 
Development  Phase  to  readily  allow  component  breakout  for  competitive 
procurement  or  as  government-furnished  equipment  (GFE)  to  maximize  cost 
savings  and  to  ensure  system  compatibility. 

Figure  1-6  shows  the  interfaces  of  events,  documents,  and  organiza¬ 
tions  in  the  acquisition  process.  Figure  1-7  presents  a  summary  over¬ 
view  of  the  acquisition  process.  There  will  be  some  variation  from  the 
pattern  indicated  het e  as  each  PM,  with  the  consent  of  the  appropriate 
PDA,  tailors  his  acquisition  strategy  to  suit  the  need  of  his  program. 
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FIGURE  1-7.  Summary  Overview  of  the  Acquisition  Process, 
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ACQUISITION  PRINCIPLES 


In  addition  to  the  critical  topics  covered  in  Section  4,  a  PM 
should  be  aware  of  the  24  acquisition  principles  enumerated  below. 
These  principles  are  based,  in  part,  on  the  DOD  Acquisition  Improvement 
Program  -  the  "Carlucci  Initiatives."  The  principles  emphasize  sound 
business  and  management  practices  that  require  action  by  the  PM  through¬ 
out  each  phase  of  the  acquisition. 

1.  Responsibility,  authority,  and  accountability  for  programs 
shall  be  placed  at  the  lowest  level  of  an  organization  at  which  effec¬ 
tive  management  of  the  program  can  be  accomplished. 

2.  PMs  shall  have  responsibility,  authority,  resources,  and  a 
properly  documented  statement  of  requirements  and  funding  to  enable 
accomplishment  of  the  assigned  task. 

3.  PMs  shall  have  authority  to  exercise  flexibility  in  tailoring 
the  acquisition  strategy. 

4.  PMs  shall  evaluate  alternatives  which  rely  on  evolutionary  low- 
risk  technology  during  acquisition  strategy  formulation,  along  with 
those  that  rely  on  advanced  high-risk  technology. 

5.  PMs  shall  consider  P  I  in  developing  the  basic  program  plan. 

6.  Pursuit  of  economical  rates  of  production,  tempered  by  appro¬ 
priate  constraints,  is  a  fundamental  goal. 

7.  A  vigorous  policy  of  standardization  shall  be  considered  in  all 
acquisition  programs  and  pursued  when  beneficial. 

8.  All  DON  personnel  shall  maintain  a  business-like  approach  with 
industry,  fundamental  to  successful  motivation  and  teamwork. 

9.  Industry  comment  on  draft  requests  for  proposal  shall  be  soli¬ 
cited  when  it  appears  to  be  beneficial  to  efficient  and  effective  execu¬ 
tion  of  the  program. 

10.  Industry  shall  not  be  mislead  regarding  the  status  of  a  pro¬ 
gram  or  the  availability  of  funding. 

11.  Acquisition  strategies  shall  recognize  the  importance  of  ob¬ 
taining  and  maintaining  a  viable  industrial  base. 

12.  Data  shall  only  be  procured  when  there  is  a  specific  need  and 
shall  be  sufficient  to  support  planned  life-cycle  maintenance. 

13.  Effective  estimating  resources  shall  be  provided  and  utilized 
in  all  program  phases. 

14.  Program  budget  and  schedule  profiles  shall  reflect  realistic 
program  estimates. 
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15.  The  acquisition  strategy  and  program  alternatives  shall  be 
formulated  with  due  regard  to  the  minimization  of  total  life-cycle 
costs. 

16.  Acquisition  managers  shall  actively  participate  in  cost  sav¬ 
ings  programs.  Value  engineering  shall  be  emphasized. 

17.  Multi-year  procurement  shall  be  considered  in  all  applicable 
situations. 

18.  Contract  negotiations  shall  be  based  on  an  independent  Navy 
cost  analysis  whenever  it  is  possible  to  develop  such  an  analysis. 

19.  Competition  shall  be  vigorously  pursued  when  there  is  a  poten¬ 
tial  for  beneficial  results. 

20.  Contract  changes  shall  be  minimized  and  when  issued,  they 
shall  be  adjudicated  as  expeditiously  as  possible. 

21.  The  acquisition  process  shall  be  expedited  to  the  maximum 
extent  possible.  The  use  of  class  determinations  and  findings  shall  be 
maximized  and  consideration  shall  be  given  to  combining  the  Source 
Selection  Authority  and  the  Source  Selection  Council  Chairman  where 
appropriate. 

22.  Past  performance  or  experience  shall  be  recognized  during 
source  selection  and  cost  realism  shall  normally  be  used  as  a  selection 
criteria  in  cost  reimbursable  contracts. 

23.  Reliability,  maintainability  and  producibility  shall  be  empha¬ 
sized  commencing  with  initial  design. 

24.  Logistic  support  standards  shall  not  be  compromised. 


Section  2 


PROGRAM  MANAGEMENT 


ROLE  OF  THE  PROGRAM  MANAGER  (PM) 

PMs,  within  their  chartered  responsibility,  shall  exercise  techni¬ 
cal  and  business/financial  management  for  the  accomplishment  of  the 
program  objectives  within  approved  constraints  and  thresholds.  In  order 
to  do  this,  the  PM  will  need  to  develop  a  broad  array  of  managerial 
skills.  Many  of  these  skills  will  have  their  locus  in  the  program 
management  organization  and  support  activities,  but  certain  ones  must 
reside  in  the  PM  himself. 

NOTE:  To  reduce  the  number  of  PMs  reporting  to  a  SYSCOM  Com¬ 
mander,  the  SYSCOM  may,  in  accordance  with  SECNAVINST  5000.1, 
and  where  necessary  or  advisable,  designate  a  Program  Director 
(PD)  over  several  PMs  for  projects  in  a  particular  warfare  or 
mission  area.  A  PD  is  a  line  authority  and  no  PM  shall  be 
responsible  to  more  than  two  levels  of  line  authority  below 
CNM.  The  designation  of  a  PD  does  not  alter  the  command  or 
major-command-equivalent  status  of  the  subordinate  PM. 

The  PM  will  be  the  primary  advocate  for  the  program.  At  the  out¬ 
set,  the  prospective  PM  must  be  thoroughly  convinced  of  the  need  which 
the  program  addresses  before  he  takes  on  the  PM  responsibility.  He  must 
completely  understand  the  military  need  for  the  system  and  must  become 
intimately  familiar  with  the  system  as  it  evolves.  Since  a  series  of 
minor  decisions  can  have  a  major  impact  on  the  program,  the  PM  must 
understand  and  appreciate  the  implications  of  each  trade-off  decision. 

The  PM  must  understand  that  he  and  he  alone  is  responsible  and 
accountable  for  the  success  or  failure  of  the  program.  He  will  get  much 
free  advice  -  some  of  it  of  little  value  -  from  all  levels  in  the 
management  hierarchy.  Advice  can  be  helpful,  but  the  buck  stops  with 
the  PM  except  when  he  is  directed,  in  writing,  by  higher  authority. 
While  the  PM  must  be  responsive  to  higher  authority,  he  cannot  be  pas¬ 
sive  with  regards  to  the  needs  of  his  program.  Since  he  is  the  primary 
advocate  for  the  program,  he  must  actively  seek  the  necessary  support 
from  higher  authority. 

The  other  side  of  the  issue  bears  noting  as  well.  Seeking  out  and 
listening  to  "good  news"  and  advice  from  those  who  will  corroborate  the 
PM's  viewpoint  can  be  dangerous.  He  must  establish  a  system  for  gather¬ 
ing,  as  early  as  possible,  all  program-relevant  information  so  that  he 
can  act  on  the  information  while  options  are  still  open. 

The  PM  must  learn,  as  soon  as  possible,  the  entire  environment  - 
up,  down,  inside  and  outside  of  the  Government  -  within  which  the 
program  exists  (Figure  2-1).  In  this  connection,  it  would  be  most 
helpful  to  have  on  the  staff  one  or  more  people  who  are  intimately 
familiar  with  the  organizational  and  political  system  and  who  can  get 
things  done.  The  PM  must  know  who  is  active,  who  is  passive,  where 
funds  come  from  and  how  they  get  to  the  program,  and  who  can  be  relied 


on  for  good,  sound,  technical  advice.  A  champion  within  the  upper 
levels  of  the  Office  of  the  Chief  of  Naval  Operations  (OPNAV),  Office  of 
the  SECDEF  (OSD),  and/or  Congress  can  be  invaluable.  It.  is  worth  the 
PM's  investment  of  time  to  keep  such  individuals  informed  and  involved. 


FIGURE  2-1.  External  Influences  on  Program  Management  Decisions. 


Finally,  the  PM  must  manage  effectively.  In  executing  the  program 
assignment,  he  will  draw  heavily  on  experts  from  many  functional  organi¬ 
zations  and  will  establish  lines  of  organizational  control.  There  are 
three  cardinal  rules  for  the  PM  to  follow: 

1.  Don't  try  to  do  everything  yourself.  Accomplish  your  purposes 
by  working  with  and  through  your  program  organization.  Develop  a  compe¬ 
tent  staff  and  use  them. 

2.  Plan  the  work  ...  then  work  the  plan 

3.  Organize  your  resources  to  fit  the  program.  Ensure  that  every¬ 
one  having  anything  to  do  with  the  program  knows  the  organization  and 
how  it  is  intended  to  work.  Insist  that  everyone  work  within  the  con¬ 
straints  of  the  organization  unless  you  authorize  a  deviation. 


PROGRAM  MANAGER  (PM)  RELATIONSHIPS 


The  PM  has  less  control  over  his  relationship  upward  than  those 
downward.  Upward  relationships  will  in  large  measure  be  determined  by 
the  military/governmental  matrix  within  which  the  program  must  be  pursu¬ 
ed.  Certain  specific  relationships  will  be  described  in  the  PM's  char¬ 
ter.  The  prime  obligation  that  the  PM  has  to  those  above  him  is  to 
provide  them  with  a  steady,  reliable  flow  of  timely  information  about 
the  program. 

If  a  serious  problem  develops  within  the  program,  it  is  better  that 
the  program  sponsors  in  the  SYSCOM,  NAVMAT  and  OPNAY  get  the  bad  news 
from  the  PM  rather  than  from  someone  else  who  does  not  have  the  PM's 
comprehensive  view  of  the  relationship  of  the  problem  to  the  entire 
program.  This  does  not  mean  that  the  PM  should  be  an  alarmist.  How¬ 
ever,  it  may  be  appropriate,  on  occasion,  to  "raise  a  pink  flag"  in  the 
form  of  informal  liaison  with  his  sponsor.  Candor  at  an  early  stage 
will  help  to  establish  and  later  to  maintain  the  PM's  credibility  with 
his  sponsor  if  a  minor  problem  develops  into  a  major  one.  No  major 
system  acquisition  program  is  without  problems,  and  these  should  be 
solved  by  tackling  them  directly,  in  the  open,  as  soon  as  they  develop. 
It  is  not  a  sign  of  weakness  to  bring  the  necessary  expert  or  back-up 
support  to  meetings  of  critical  issues. 

At  the  earliest  stages  of  the  project,  the  PM  will  have  consider¬ 
able  flexibility  in  establishing  the  relationships  within  his  organiza¬ 
tion  and  between  himself  and  elements  of  that  organization.  These 
relationships  are  subject  to  change  at  any  time  during  the  program  if 
the  PM  finds  that  this  will  help  him  more  effectively  accomplish  program 
goals  and  so  long  as  these  changes  are  not  inconsistent  with  the  poli¬ 
cies  and  procedures  established  by  higher  authority.  At  any  given 
point,  however,  the  relationships  should  be  treated  as  fixed.  Reorgani¬ 
zation  must  not  be  used  as  a  cosmetic  to  cover  inadequacies  in  program 
accomplishments  and  planning.  Reorganization  may  be  harmful  to  the 
program  because  it  disrupts  personal  commitments  and  communication 
links,  and  may  dilute  corporate  memory  in  the  areas  changed. 

The  tone  set  by  the  PM  in  his  relationship  with  his  sponsors  and 
those  above  him  will  be  reflected  in  his  relationships  with  the  program 
management  team.  If  a  team  spirit  can  be  instilled  in  the  program 
personnel,  they  will  perform  their  work  more  effectively.  It  is  impor¬ 
tant  that  the  organizational  diagram  not  be  contrary  to  the  existing 
assignments  of  organizational  functions,  but  this  does  not  require 
slavish  adherence  to  form.  Team  members  should  be  encouraged  to  assume 
more  than  the  minimal  responsibilities  required  by  their  job  descrip¬ 
tion,  particularly  in  the  area  of  identifying  and  giving  visibility  to 
potential  problems.  The  PM's  support  of  his  team  members  promotes 
subordinate  responsibility  and  team  spirit.  Although  it  is  not  a  re¬ 
quirement  and  is  seldom  done,  primarily  because  of  time  and  other  pres¬ 
sures,  it  would  be  well  for  the  PM  to  take  hi'*  entire  management/support 
team  aside  to  develop  a  mutual  understanding  of  the  organizational 
interfaces  and  how  the  management  structure  is  to  function  as  well  as  to 
establish  interpersonal  rapport. 


The  Program  Coordinator /Development  Coordinator 


Organizational  interfaces  are  extremely  important.  Within  NAVMAT, 
these  are  stipulated  and  controlled  through  the  PM's  charter.  The  PM's 
contacts  with  the  DON  outside  of  NAVMAT,  i.e.,  OPNAV,  OSD,  Office  of 
Management  and  Budget  (0MB),  Congress,  etc.,  are  established  primarily 
by  working  with  and  through  the  OPNAV  program  coordinator  and  develop¬ 
ment  coordinator. 

The  program  coordinator  is  the  OPNAV  official  responsible  to  the 
program  sponsor  (the  Deputy  CNO  (DCNO)  or  the  Director,  Major  Staff 
Office  (DMSO),  for  a  force,  platform,  or  support  area).  The  development 
coordinator  is  an  official  on  the  staff  of  the  OPNAV  appropriation 
sponsor.  For  the  RDT&E,N  appropriation  this  is  the  Director,  RDT&E  (0P- 
098).  The  PM  is  the  principal  contact  with  the  program  coordinator  and 
development  coordinator  for  all  matter  relating  to  the  program.  The 
Navy  Programming  Manual  describes  these  relationships  further. 

Both  the  program  coordinator  and  the  development  coordinator  are 
concerned  with  more  than  one  program;  therefore,  it  is  up  to  the  PM  to 
make  his  relationships  with  them  work.  To  do  this,  the  PM  must  supply 
useful  and  correct  information.  He  needs  the  wholehearted  cooperation 
of  the  program  coordinator  and  development  coordinator,  especially  in 
defending  the  program's  budget.  Figure  2-2  illustrates  the  PM/program 
coordinator/development  coordinator  relationship. 


FIGURE  2-2.  PM/Program  Coordinator/Development  Coordinator  Interface 
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The  PH  assesses  the  progress  of  the  project  against  the  require¬ 
ments  levied,  identifies  any  need  for  modification  Of  the  requirements, 
and  obtains  OPNAV  approval  of  required  changes.  The  program  coordinator 
typically  acts  as  the  focal  point  for  the  PM  for  all  contacts  within 
OPNAV  and  participates  with  the  PM  in  the  preparation  and  presentation 
of  proposed  project  actions  to  higher  authority. 

Collectively  the  PM,  program  coordinator,  and  development  coordina¬ 
tor  bring  managerial  objectivety  to  the  program.  The  PM,  being  hard¬ 
ware-oriented,  relates  roftware,  personnel,  and  facilities  to  the  devel¬ 
opment  and  acquisition  of  the  hardware  elements  of  the  system.  The 
program  coordinator  and  development  coordinator  maintain  an  overview  of 
program  activities  from  the  point  of  view  of  OPNAV  and  the  operating 
forces,  determine  whether  or  not  the  program  Is  proceeding  in  accordance 
with  the  need  documents,  and  facilitate  the  coordination  of  programming 
actions  within  OPNAV. 


Ethics 

A  PM,  if  he  does  not  know  it  already,  will  soon  learn  that  if  he 
desires,  he  and  many  of  his  staff  and  team  members  will  be  courted 
assiduously  by  a  great  variety  of  industrial  concerns  wanting  to  estab¬ 
lish  and/or  maintain  cordial  contract  relations  in  support  of  the  pro¬ 
gram.  The  Navy  and  Marine  Corps  are  justifiably  proud  of  the  accom¬ 
plishments  and  special  efforts  of  their  military  and  civilian  team.  It 
has  therefore  been  terribly  disappointing  to  find  that  a  few  individ¬ 
uals  have  tarnished  the  Navy/Marine  Corps  reputation  by  defrauding  the 
government,  wasting  government  resources,  or  abusing  positions  of  trust 
for  personal  gain.  The  Chief  of  Naval  Operations  (CNO)  and  the  Secre¬ 
tary  of  the  Navy  (SECNAV )  have  made  elimination  of  fraud,  waste,  and 
abuse  their  personal  goal.  Congress,  in  reaction  to  lapses  in  the 
ethics  of  government  employees,  has  enacted  legislation  establishing 
higher  standards  of  conduct  within  the  Ethics  in  Government  Act  of  1978. 

The  PM  must  be  rigidly  ethical  in  all  his  dealings  with  contractors 
and  must  see  that  everyone  in  his  organization  follows  his  example. 
Although  it  is  not  likely  that  a  PM  or  any  other  team  member  would 
compromise  his  integrity  or  allow  the  success  of  the  program  to  be 
jeopardized  for  the  price  of  a  lunch,  the  FM  and  all  others  should 
realize  that,  like  Caesar's  wire,  they  must  not  only  be  above  reproach 
but  must  also  give  the  appearance  of  being  so.  Being  discreet  is  not 
enough.  Acceptance  of  such  emoluments  makes  it  increasingly  more  diffi- 
cu’t  to  render  objective  decisions  on  contractor/government  disputes  and 
other  differences  of  opinion  with  the  contractor  that  might  arise  from 
time  to  time.  Specifically,  the  PM  and  his  staff  should  avoid  any 
action  which  might  result  in,  or  create  the  appearance  of: 

1.  Using  a  government  position  for  private  gain. 

2.  Giving  preferential  treatment  to  any  person  or  organization. 

3.  Impeding  government  efficiency  or  economy. 

4.  Losing  complete  independence  or  impartiality. 

5.  Making  a  government  decision  outside  official  channels. 

6.  Adversely  affecting  the  confidence  of  the  public  in  the  integ¬ 
rity  of  the  Government. 
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Program  Manager's  (PM's)  Charter 


The  new  PM  may  be  report  directly  to  the  Chief  of  Naval  Material 
(CNM)  or  to  the  Systems  Command  (SVSCOM)  Commander  whose  mission  most 
directly  relates  to  the  program.  For  ACAT  I  and  IIS  programs,  a  PM  must 
report  directly  to  the  CNM  or  SYSCOM  Commander,  except  a  SYSCOM  Comman¬ 
der  may,  if  necessary  or  advisable,  designate  a  Program  Director  over 
several  PMs  for  a  particular  warfare/mission  area.  No  PM  shall  report 
to  more  than  2  levels  of  authority  below  the  CNM.  The  PM  is  charged 
with  responsibility  for  acquiring  and  fielding,  in  accordance  with  the 
instructions  from  line  authority,  a  cost-effective  solution  to  the 
approved  mission  need  that  can  be  operated  and  supported  within  avail¬ 
able  resources  -  the  resources  projected  in  the  milestone  decision 
memorandum.  The  precise  scope  of  his  responsibility  and  authority  will 
normally  be  delineated  in  his  charter.  In  the  real  world,  not  all 
significant  acquisition  programs  are  managed  by  formally  chartered  mana¬ 
gers.  The  effectiveness  of  the  PM  depends  largely  on  the  authority  that 
he  exercises  through  persuasiveness  and  by  fostering  teamwork. 

The  charter  is  a  document  promulgated  by  a  Naval  Material  Command 
(NAVMAT)  or  SYSCOM  directive,  depending  upon  whether  or  not  it  is  a  CNM- 
or  a  SYSCOM-maneged  program.  It  defines  the  PM's  mission,  and  responsi¬ 
bilities,  and  describes  his  relationships  with  other  organizations  and 
activities.  It  will  also  include  assignment  of  a  technical  manager/sys¬ 
tems  engineer,  a  business/financial  manager  and  a  logistics  manager,  as 
well  as  the  designation  of  a  contracting  officer  who  shall  be  responsi¬ 
ble  for  all  contractual  matters  relating  to  the  program.  Other  func¬ 
tional  support  required  by  the  FM  such  as  assignment  of  a  lead  labora¬ 
tory,  when  appropriate,  will  be  identified  in  the  charter.  Figure  2-3 
provides  the  outline  of  a  PM  charter.  A  more  complete  discussion  of  the 
charter  is  set  out  in  the  governing  instruction,  NAVMATINST  5000.21. 


TITLE 

1.  System  Description.  An  unclassified  description  of  the  deliverable  end  items. 

2.  Scope  of  the  Program. 

3.  Authorities.  Include'ipecial  authorities  which  are  unusual  or  peculiar  to  the  program. 

4.  Limitation  of  Authority. 

5.  Responsibilities.  Include  special  responsibilities  which  are  unusual  or  peculiar  to  the  program. 

6.  Relationship  to  Chartering  Authority. 

7.  Special  Operating  Relationships. 

a.  Relationships  with  activities  above  the  NAVMAT  level  or  outside  of  the  Navy  Department. 

b.  Relationships  with  activities  at  the  NAVMAT  level. 

c.  Relationships  with  activities  at  the  SYSCOM  level. 

d.  Relationships  with  field  level  activities. 

8.  Supporting  (Participating!  Organizations. 

9.  Initial  Staffing  and  Organization. 

10.  Program  Transition  or  Disestablishment, 


FIGURE-  2-3.  Outline  of  the  Program  Manager's  Charter. 
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The  charter  is  a  mutually  agreed-to  contract  between  the  PM  ana  his 
superiors.  It  is  prepared  by  NAVMAT  with  the  assistance  of  the  PM  or 
SYSCOM  personnel,  or  both,  and  approved  by  CNM.  Due  to  its  contractual 
nature,  the  PM  should  ensure  that  the  charter  provides  an  adequate 
framework  within  which  he  can  function  effectively.  All  PM  charters  are 
submitted  through  MAT-08P  for  coordination  and  are  approved  by  the  CNM 
before  promulgation.  Once  the  charter  is  approved,  any  program  deci¬ 
sions  made  by  line  officials  above  the  PM  in  the  chain  of  command  are  to 
be  documented  in  writing.  At  that  point,  the  line  official  becomes 
accountable  for  the  decision  and  its  consequences. 


PROGRAM  MANAGER'S  (PM'S)  EFFORT 

The  PM  must  see  that  there  is  sufficient,  factual  information 
generated  in  each  phase  of  the  acquisition  process  to  permit  intelligent 
recommendations  to  be  made  to  the  program  decision  authority  (PDA)for 
the  conduct  of  the  next  phase.  He  must  develop  (independently,  but  with 
appropriate  contractor  inputs)  such  documentation  as  the  Test  and  Eval¬ 
uation  Master  Plan  (TEMP),  the  Integrated  Logistic  Support  Plan  (ILSP), 
the  Naval  Training  Plan  (NTP),  plans  for  manpower,  personnel  and  train¬ 
ing  support  (MP&TS),  independent  life-cycle  cost  (LCC)  analysis,  risk 
analysis,  survivability/vulr.erability  analysis,  system  safety  program 
plan,  mission  profile  definition,  and  system  software  definition. 
(These  subjects  are  discussed  in  more  detail  in  Section  4,  Critical 
Topics)  The  PM  must  also  oversee  the  conduct  of  the  RDT&E  and  produc¬ 
tion  program  and  conduct  trade-off  analyses  of  the  competitive  systems. 
He  may  find  it  necessary  to  initiate  parallel  or  backup  in-house  Navy 
technology  efforts  to  determine  alternative  means  for  dealing  with 
identified  high-risk  areas  and  to  develop  system  software.  A  large  part 
of  the  PM's  time  and  effort  will  be  spent  in  active  liaison  with  the  PDA 
ar.d  the  chain-of -command  leading  to  the  PDA,  informing  them  of  the 
program's  progress  and  possible  problems,  and  justifying  the  program 
funding  and  objectives. 


PROGRAM  MANAGER  (PM)  SUPPORT 

While  responsibility  for  the  success  or  failure  of  a  program  rests 
on  the  PM's  shoulders,  he  is  helpless  alone  and  requires  a  strong  sup¬ 
port  team  for  the  successful  completion  of  his  program.  Thus  the  single 
most  important  management  element  for  the  PM  is  building  and  motivating 
the  program  team.  The  PM  needs  to  work  through  others. 

The  required  support  can  come  from  many  sources:  the  immediate 
PMO ,  Headquarters  support,  Navy  in-house  R&D  centers/laboratories,  T&E 
facilities  and  field  support  stations,  other  DOD  facilities.  Government 
plant  representatives,  industrial  and  consulting  organizations  (contrac¬ 
tors),  Federal  contract  research  centers  (FCRCs),  universities,  and 
other  not-for-profit  institutions. 


Matrix  Management 

Except  for  a  very  few  major  programs,  most  Navy-managed  programs 
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will  be  chartered  to  a  SYSCOM.  The  SYSCOMs,  for  the  most  part,  use 
matrix  management  systems  in  which  PMO  staffs  of  experienced  personnel 
provide  intensive  management.  The  PMQs,  in  turn,  utilize  line  function¬ 
al  organizations  for  their  program  support. 

The  matrix  management  operation  is  designed  to  give  centralized 
business  direction  to  the  large  number  of  diverse  functions  and  programs 
assigned  to  a  SYSCOM.  In  this  matrix,  the  technical  and  administrative 
experts  are  located  in  the  functional  groups,  where  they  provide  direct 
support  to  numerous  PMs  as  the  needs  arise.  As  a  rule,  they  are  not 
dedicated  to  a  single  program,  but  divide  their  time  among  all  of  the 
programs  that  require  attention  at  any  given  time. 

Such  organizational  structure  allows  a  relatively  small  number  of 
persons  to  manage  large  and  complex  programs  on  a  long-term,  dedicated 
basis  and  provides  prompt  support  for  these  program  personnel  by  specia¬ 
lists  located  in  the  individual  functional  groups.  These  specialists 
are  exposed  to  numerous  state-of-the-art  developments,  and  have  the 
advantage  of  a  synergistic  environment  in  which  lessons  learned  on  one 
program  can  be  applied  toward  solving  problems  on  other  programs. 

Since  most  of  the  PM's  assistance  will  come  directly  from  his 
parent  SYSCOM,  the  detailed  NAVMAT  and  SYSCOM  organization  charts  serve 
as  a  useful  starting  point  in  determining  what  help  is  available  and 
where  to  find  it.  The  Department  of  Defense  (DOD)  phone  book  is  another 
source  of  information  and  is  especially  useful  if  the  PM  desires  to 
determine  what  assistance  may  be  available  from  the  other  services  or  to 
compare  notes  with  a  fellow  PM,  Both  the  Defense  System  Management 
College  (DSMC)  and  the  Naval  Material  Command  (NMC)  Acquisition/Logis¬ 
tics  Management  Training  Center,  Anacostia,  are  available  for  assistance 
in  management-related  problems. 

Because  of  severe  manpower  constraints  placed  upon  the  services  and 
Congress  desire  to  minimize  the  number  of  DOD  employees  in  the  Washing¬ 
ton  area,  NAVMAT  and  the  SYSCOMs  can  typically  provide  only  a  small 
number  of  people  to  each  PM  for  the  necessary  day-to-day  support.  Also, 
as  a  result  of  the  general  reduction  in  Headquarters  personnel,  the 
"hands-on"  experience  for  which  the  SYSCOMs  were  noted  in  the  past  is 
much  diluted.  The  PM  (unless  he  is  in  charge  of  a  very  high  priority 
program)  will  find  himself  queuing  up  with  other  PMs  for  essential 
services.  The  SYSCOMs  do  retain  sufficient  technical  talent  and  insight 
into  program  technical  management  that  they  can  act  as  a  means  to  gain 
and  integrate  field  activity  support  into  matrix  program  management. 

Another  means  for  obtaining  much  needed  "headquarters"  assistance 
is  to  bring  in  specialized  personnel  from  in-house  Navy  field  stations 
and  Research  and  Development  ( R&D )  Centers  on  both  long-term  and  short¬ 
term  training  assignments.  The  use  of  the  Naval  Scientist  Training  and 
Exchange  Program  (HSTEP),  for  instance,  not  only  supplements  the  PM's 
staff,  but  serves  to  provide  valuable  training  to  the  field  personnel 
and  improve  liaison  with  the  field  stations.  The  Director  of  Navy 
Laboratories,  MAT-05,  can  assist  in  this  area. 

In  recent  years,  increased  use  has  been  made  of  contractors  to 
assist  in  the  documentation  and  coordination  tasks  so  necessary  to  most 
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programs  and  to  provide  technical  staff  assistance,  such  as  preparing 
technical  documentation.  Frequently  a  contract,  which  allows  for  addi¬ 
tional  task  assignments,  has  already  been  let  for  such  assistance  by  the 
parent  SYSCOM.  The  PM  should  inquire  within  his  Command  as  to  what 
assistance  contract  may  be  in  existence  and  how  he  can  obtain  the  needed 
support  services.  Some  of  the  advantages,  limitations,  and  controls 
that  affect  the  use  of  Contract  Support  Services  are  presented  later  in 
this  section. 

Functions  that  are  by  their  nature  restricted  to  the  government 
must  not  be  allowed  to  come  under  contractor  control.  Similarly,  con¬ 
tractor  support  should  not  be  utilized  for  matters  where  government 
corporate -memory  is  required.  In  these  areas,  every  attempt  should  be 
made  to  assign  the  efforts  to  a  field  activity  and  ensure  that  the 
activity  is  made  aware  of  the  need  for  long-term  corporate  memory  re¬ 
quirements. 


Responsive  versus  Responsible.  The  PM  is  the  individual  ultimately 
responsible  and  accountable  for  success  or  failure  of  the  program.  He 
must  delegate  authority  to  a  variety  of  agencies  and  individuals  within 
and  without  the  program  organization:  support  facilities,  program  man¬ 
agement  office/organization  (PMO)  members,  contractors,  etc.  Regardless 
of  the  amount  of  authority  delegated  or  the  individual  or  agency  to  whom 
it  is  delegated,  the  PM  does  not  divest  himself  of  final  responsibility 
and  accountability. 

The  PM  has  great  latitude  in  assigning  responsibility  for  the 
various  functions  required  for  the  successful  prosecution  of  his  pro¬ 
gram.  However,  certain  functions  by  their  nature  must  be  performed 
within  the  Government.  Among  these  innately  governmental  functions  are: 


1. 

The  determination  of  needs  and  the  definition  of 
that  must  be  met  by  the  program. 

requirements 

2. 

Decisions  as  to  operational  use. 

3. 

Protection  of  the  taxpayer  by  the  most  cost-effective  use  of 
available  funds. 

4. 

The  final  decision  as  to  whether  or  not  the  end 
service  needs. 

product  meets 

5. 

The  overall  management  of  the  program. 

Government  agencies  cannot  divest  themselves  of  their  responsibili¬ 
ties  by  re-assigning  them  to  non-government  agencies  through  the  con¬ 
tracting  process.  The  act  of  contracting  for  portions  of  the  program 
merely  represents  the  assignment  of  specific  responsibilities  and  the 
delegation  of  certain  authority  to  the  contractor.  While  it  is  essen¬ 
tial  to  the  success  of  the  program  that  these  contracts  be  managed 
effectively  and  efficiently,  it  is  equally  important  that  the  PMO  itself 
be  organized  and  administered  in  an  effective,  efficient  manner. 

Most  programs  are  managed  under  the  matrix  management  scheme  where- 


in  the  program  is  run  by  a  small  staff  of  specialists  who  look  to  the 
functional  groups  and  field  activities  in  the  specialty  areas.  Thus  the 
only  team  members  of  a  given  program  who  are  line-responsible  to  the  PM 
are  those  on  his  immediate  staff  -  all  others  on  the  program  team  being 
line-responsible  within  the  functional  groups  of  the  parent  command  but 
at  the  same  time  being  responsive  to  the  PM  in  accordance  with  the 
program  organizational  diagram. 

This  concept  of  being  responsible  within  one  organization  and  at 
the  same  time  being  responsive  in  an  entirely  different  one  is  often 
confusing  to  the  functional  group  team  members  and  sometimes  frustrating 
to  the  PMO.  However,  the  benefits  accruing  to  the  PM  from  this  type  of 
organization  are  (1)  oversight  by  the  tasked  organization  of  work  as¬ 
signed,  (2)  assurance  that  the  work  conforms  to  standards  In  the  speci¬ 
alty  area,  and  (3)  access  to  the  synergistic  advantages  of  dealing  with 
an  organization  intimately  involved  in  the  specialty  field.  Functional 
group  and  field-activity  team  personnel  know  whom  they  are  responsible 
to  and  their  functional  group  or  field  activity  homes,  but  they  do  not 
always  know  to  whom  they  are  to  be  responsive  in  the  program  line.  In 
this  regard,  it  is  not  sufficient  to  give  the  simplistic  response  that 
all  team  members  must  be  responsive  to  the  PM.  The  real  question  is 
"Through  whom  are  they  to  be  responsive  to  the  PM?" 


Program  Management  Organizational  Structure 

PMs  have  a  limited  span  of  control  so  that  it  becomes  essential 
that  program  chains-of -command  be  established.  This  can  best  be  done  by 
means  of  a  structured  organization,  which  should  be  documented  by  a 
program  organization  diagram.  To  be  useful,  the  organizational  diagram 
must  clearly  show  the  program  organizational  relationships  that  are 
intended.  There  must  be  no  difference  between  the  way  the  diagram  is 
drawn  and  the  way  the  personnel  interactions  occur.  It  is  counterpro¬ 
ductive  for  the  PM  or  any  member  of  his  staff  to  say  of  the  diagram, 
"This  is  the  way  we  show  it  but  not  the  way  it  really  works".  If  it 
turns  out.  that  there  is  a  discrepancy  between  the  way  the  organization 
is  shown  and  the  way  it  works,  one  or  the  other  should  be  modified. 
Organizational  anarchy  does  not  typify  the  well -managed  program. 


Types  of  Program  Management  Organizations  (PMOs).  Because  of  limi¬ 
ted  resources^  Navy  program  management  philosophy  usually  provides  for 
modest  permanent  staffing  of  the  immediate  program  office,  and  requires 
the  PM  to  obtain  support  and  assistance  from  headquarters  functional 
groups.  Navy  field  activities,  and  contractors.  The  PM  should  aim  for  a 
lean,  committed,  program  staff.  One  good  worker  is  worth  five  mediocre 
ones.  It  is  better  to  not  fill  a  position  than  to  fill  it  with  someone 
who  cannot,  or  will  not,  do  the  job.  The  PM  should  pick  his  people 
carefully.  The  easiest  way  to  manage  is  to  surround  himself  with  good 
people,  and  give  them  the  freedom  to  do  the  job. 

The  program  must  interface  effectively  with  the  parent  Command.  To 
facilitate  this,  a  matrix-type  of  organization  has  proved  to  be  effici¬ 
ent  and,  with  reduced  personnel  levels,  often  necessary.  In  matrix 
management,  the  designated  PM  is  the  management  authority  for  the  pro- 
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gram  and  makes  all  decisions  concerning  its  prosecution.  The  functional 
groups  in  the  SYSCOMs,  R&D  centers,  and  field  activities  provide  the  in- 
house  scientific,  technical,  contracting,  legal  expertise,  and  when 
called  for,  detailed  management  of  the  participating  contractors. 
Special  tasks  for  the  PMO  may  be  performed  by  field  activities  or  under 
contract  with  industry.  Among  alternative  PMO  types  that  have  been  used 
successfully  are;  (1)  the  fully  staffed  integral  PMO  (such  as  PM-1  or 
PM-3);  (2)  a  small  PMO  supported  by  SYSCOM  Headquarters  functional 
groups;  and  (3)  a  skeleton  Washington  SYSCOM  office  augmented  by  the 
technical  manager  or  assistant  technical  manager  and  more  complete  staff 
at  a  field  station.  Figure  2-4  is  an  example  of  a  PMO  combining  types 
(2)  and  (3);  Figure  2-5  is  an  example  of  a  PMO  characteristic  of  a 
NAVSEA  ship  development. 


Acquisition  Team 

The  charter  will  set  out,  as  a  minimum,  the  major  initial  organiza¬ 
tional  groupings  of  the  program  office  and  the  initial  staffing  objec¬ 
tives  by  number,  rank,  and  grade  level.  A  business/financial  manager,  a 
logistics  manager,  a  technical  manager/ system  engineer,  and  a  contract¬ 
ing  officer  will  be  assigned,  however  the  PM  does  have  some  influence  on 
these  choices.  Compatibility,  complementary  expertise,  and  mutual  re¬ 
spect  between  members  of  the  acquisition  team  are  essential. 

Additional  administrative  and  program  acquisition  requirements  have 
placed  a  serious  time-management  burden  on  the  PM.  As  a  result,  program 
details  frequently  do  not  receive  enough  attention  from  the  PM.  As  one 
solution,  a  deputy  program  manager  (DPM)  may  be  used.  The  DPM  should  be 
assigned  generic  duties  and  responsibilities,  and  delegated  sufficient 
authority  to  ease  the  workload  of  the  PM. 


Decision  Levels  and  Assignment  of  Responsibilities.  Since  manage¬ 
ment  of  a  program  involves  a  multitude  of  decisions  of  various  degrees 
of  complexity  and  importance,  it  is  obvious  that  the  PM  cannot,  and 
should  not,  try  to  make  all  of  the  decisions.  Probably  the  most  effec¬ 
tive  place  for  decisions  to  be  made  is  at  the  lowest  level  having  the 
capability  and  the  requisite  responsibility  and  authority  to  do  so.  It 
is  important,  therefore,  that  assignment  of  responsibility  and  delega¬ 
tion  of  authority  be  logically  made  and  carefully  defined  (the  use  of 
the  WBS  and  the  accountability  matrix  in  this  application  is  mentioned 
earlier). 

Prefabricated  Decisions.  In  many  instances,  there  are  similar 
situations  that  arise  frequently.  These  recurring  situations  should  be 
resolved  by  established  policy  rather  than  by  repetitive  independent 
(and  possibly  contradictory)  decisions.  Such  policies  assure  uniformity 
and  probably  decrease  the  numbers  and  complexity  and  facilitate  the 
making  of  decisions  by  lower  level  managers.  Many  policies  and  stan¬ 
dards  are  imposed  by  the  DON  and  DOD  and  are  promulgated  in  various 
instructions  and  MIl.-STDs.  Contractors  and  field  activities  may  also 
have  certain  policies  that  will  affect  their  efforts  on  the  program.  It 
is  imperative  that  the  PM  be  aware  of  and  understand  any  possible  ef¬ 
fects  of  such  policies.  Additionally,  the  PM  may  want  to  establish 


- •  LINE  AUTHOHITY 

-  - - ADVISORY  MONITOR 

•  —  separates  arenas.  ho».  f  ielo.  industry 


APU  -  ASSISTANT  PROGRAM  MANAGER 

ATM  -  ASSISTANT  TECHNICAL  MANAGER 

■  X  -  BUSINESS  MANAGER 

CO  -  contracting  officer 


LM  -  LOGISTICS  MANAGER 
NAVPRO-  NAVAL  PLANT  REPRESENTATIVE 
OFFICE 

PSO  —  PROGRAM  SUPPORT  OFFICE 

HP  -  TECHNICAL  MANAGER 


FIGURE  2-4.  Sample  Program  Management  Organization. 


APM  -  ASSISTANT  PROGRAM  MANAGER  GFI  -  GOVERNMENT  FURNISHED  INFORMATION 

GFE  -  GOVERNMENT  FURNISHED  EQUIPMENT  ILS  -  INTEGRATED  LOGISTICS  SUPPORT 


FIGURE  2-5.  Typical  Ship  Program  Management  Organization. 
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policies  or  standards  peculiar  to  his  program.  If  he  does  so,  they 
should  be  logical,  effective,  explicitly  defined,  and  carefully  ob¬ 
served;  above  all,  they  should  not  be  in  conflict  with  existing  DOO  and 
DON  directives  and  instructions. 


Relationship  of  PMO  to  Other  Organizations.  The  PM  must  exercise 
care  in  setting  up  the  program  management  organization,  in  establishing 
its  methods?  of  operation,  and  in  making  those  methods  of  operation  known 
to  all.  Especially  critical  is  the  need  for  establishing  direct  liaison 
between  the  in-house  functional  organizations  and  industry.  During  the 
competitive  Concept  Exploration  Phase,  all  contacts  between  the  PMO  and 
the  contractors  must  be  carefully  controlled  to  ensure  that  the  partici¬ 
pating  contractors  are  treated  equally  and  that  competition  is  not 
interfered  with.  In  all  phases,  the  PM  must  insist  that  the  established 
methods  of  operation  be  adhered  to.  By  so  doing,  he  can  prevent  the 
contractors  and  others  from  making  end  runs  around  his  technical  staff 
and  other  in-house  support,  and  thereby  undermining  their  responsibili¬ 
ties  and  authority.  The  basic  management  philosophy  of  command  applies: 
delegation  of  authority  and  limited  span  of  control. 


Contractor  Team.  0MB  Circulars  A-76  and  A-109,  as  well  as  the  DOD 
and  Department  of  the  Navy  (DON)  directives  and  instructions  governing 
the  acquisition  process,  stress  the  need  for  government  reliance  on  the 
private  sector,  particularly  for  production  and  the  engineering  leading 
to  rroduction.  The  means  for  obtaining  this  support  is  the  contract. 
The  obtaining  of  a  good  contract,  one  that  accurately  describes  the 
products  to  be  produced,  the  relationships  between  the  parties,  and 
which  is  fair  to  both  sides,  is  critical  to  the  success  of  the  program. 
Contracting  is  discussed  in  more  detail  in  Section  4.  Obtaining,  moni¬ 
toring  and  managing  contracts  involves  the  close  cooperation  of  the  PM, 
the  business/financial  manager,  the  technical  manager  and  especially  the 
contracting  officer.  The  same  procedures  for  utilizing  contractor  sup¬ 
port  will  apply  to  FCRCs  and  not-for-profit  institutions,  although  these 
organizations  do  not  have  the  production  capabilities  nor  the  same 
degree  of  profit  motivation  found  in  the  industrial  sector. 

Contracting  Team.  The  PM  must  depend  upon  others  to  carry  out  the 
details  for  contracting  with  industry.  To  this  end,  he  must  establish  a 
team  of  capable  specialists.  The  functions  performed  by  the  contracting 
team  and,  hence,  the  size  of  the  team  may  vary  as  the  program  progresses 
through  the  acquisition  process.  The  PM  must  identify  the  functional 
makeup  of  the  contracting  team  and  devote  a  considerable  amount  of 
attention  to  ensuring  that  the  functions  are  staffed  adequately  and  in  a 
timely  manner. 

Contracting  Officer.-  There  are  two  interdependent  facets  to  the 
contracting  process  that  must  be  given  attention  by  the  contracting  team 
-  the  functional  and  the  technical.  The  contracting  representative  on 
the  team  is  the  procuring  contracting  officer  (PCO).  The  PCO  is  the 
official  government  representative  in  the  contracting  process  and  is 
responsible  for  all  activities  associated  with  the  award  of,  and  perfor¬ 
mance  under  the  contract.  The  PCO  signs  the  contract  and  only  he  can 
authorize  changes  to  it..  (Actions  of  other  team  members  may  inadver- 


tently  precipitate  changes,  but  these  frequently  lead  to  litigation  -  a 
totally  unacceptable  situation.)  While  the  PM  is  responsible  for  the 
results  of  the  contract  effort,  the  PCO  is  responsible  for  assuring  that 
all  the  contract  associated  actions  are  legal,  with  the  result  that  he 
often  exerts  a  powerful,  sometimes  overriding,  influence  on  the  contract 
itself.  The  PCO,  normally,  will  have  other  personnel  from  the  auditing 
and  contracting  communities  assist  in  the  discharge  of  responsibilities. 
These  personnel  will  include  an  administrative  contracting  officer 
(ACO),  who  is  generally  on-site  at  the  contractor's  facility.  The  ACO 
acts  on  delegated  authority  from  the  PCO  and  is  usually  a  representative 
of  the  Defense  Contract  Administrative  Service  (DCAS)  or  the  Navy  Plant 
Representative  Office  (NAVPRO).  The  ACOs  and  auditors  should  be  brought 
into  the  program  early  to  provide  the  PCO  with  pre-contract  information, 
cost  and  price  data,  and  point  out  the  strengths  and  weaknesses  of  a 
particular  contractor's  proposal. 

The  PM's  close  relationship  with  the  contracting  team,  particularly 
the  PCO  and  ACO,  is  important  for  achieving  a  smoothly  functioning 
contracting  program.  The  PM  should  be  deeply  involved  in  all  facets  of 
the  contracting  actions  involving  his  program  and  should  act  as  the 
chairman  for  all  contracting  planning  meetings. 

The  contracting  team  meet  on  a  regular  basis  for  planning  and  for 
reviewing  the  progress  made  in  implementing  the  acquisition  program. 
The  meetings  should  be  documented  and  distribution  of  the  minutes  should 
be  made  promptly. 

Team  Leaders.  Aside  from  the  schedules  planning  and  review  meet¬ 
ings,  the  PM  should  interface  with  the  contracting  team  by  working  with 
and  through  team  "leaders".  Team  leaders  should  be  selected  and  desig¬ 
nated  for  the  purpose  of  coordinating  inputs  of  team  members  for  the 
various  functional  areas.  The  team  leader's  role  is  important  and 
should  not  be  bypassed.  Although  direct  communication  between  the  PM 
and  contracting  team  member-;  is  acceptable,  the  PM  should  discourage 
meetings  among  team  members  when  their  team  leader  is  not  present.  The 
PM  however,  should  not  hes’t^te  to  seek  counsel  from  persons  external  to 
the  designated  contracting  team  for  advice  or  recommendations  on  appro¬ 
priate  strategies  whenever  vtv.  situation  warrants.  In  some  cases,  an  ad 
hoc  team  may  be  in  order. 

Contract  Administrator  UODI  4105.59  established  the  Plant  Cogni¬ 
zance  Program.  A  Navy  Plant  Representative  Office  (NAVPRO),  Supervisor 
of  Ship  Building  (SUPSHIP)  or  other  government  plant  representative 
office  -  Air  Force  Plant  Representative  Office  ( AFPRO )  or  DCAS  office  - 
may  be  established  in  or  near  a  contractor's  plant.  They  provide  con¬ 
tract  administration  services,  and  it  is  essential  that  the  PM  and  his 
team  coordinate  closely  with  them  when  dealing  with  the  contractor. 
Additional  services  that  may  be  provided  include  quality  assurance 
inspection  and  administration,  engineering  support,  production  surveil¬ 
lance,  price/cost  analysis,  and  property  administration.  A  complete 
listing  of  these  functions  are  contained  in  FAR  1-406.  When  there  is  no 
NAVPRO  or  other  government  plant  representative  office  to  perform  these 
services,  or  when  particular  technical  expertise  is  required  in  the 
course  of  PMO/  contractor  relations,  technical  personnel  from  an  in- 
house  R&D  laboratory  or  center  are  often  utilized. 
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Technical  Team.  On  the  technical  side,  the  PM  may  draw  from  his 
own  staff,  from  other  groups  in  SYSCOM  Headquarters,  or  from  Navy  labo¬ 
ratories/centers  to  obtain  the  specialized  assistance  he  may  need. 
Although  the  number,  source  and  types  of  specialists  called  for  will 
vary  with  the  scope  and  phase  of  the  program,  elements  of  the  team  are 
held  together  for  the  life  of  the  program  and  provide  continuity  and 
corporate  memory  for  the  program.  It  will  include  system  engineers, 
experts  in  specific  technologies,  specialists  in  areas  such  as  reliabil¬ 
ity,  production  engineering,  documentation,  fleet  in-service  support 
and  the  like,  as  well  as  fiscal  and  administrative  personnel  as  appro¬ 
priate. 

The  technical  team  provides  ongoing  analyses  and  decision-making 
assistance.  On  the  basis  of  past  experience  with  related  programs,  the 
support  team  can  provide  a  wealth  of  knowledge  and  lessons  learned  about 
government/contractor  interactions,  critical  design  attributes,  surviva¬ 
bility  features,  reliability,  human  engineering,  quality  assurance  pro¬ 
visions,  current  technology,  safety,  and  logistic  alternatives. 


Navy  In-House  Technical  Support.  Much  of  what  the  Navy  has  learned 
from  other  development  programs  is  available  in  the  Navy  laboratories, 
centers,  facilities  and  stations.  The  hands-on  knowledge  and  direct 
user  interface  experience  with  both  new  and  old  systems  resident  in 
these  agencies  provides  a  valuable  source  of  expertise.  To  strengthen 
this  corporate  memory  and  make  it  easier  for  the  PM  and  staff  to  use, 
NAVMAT  and  the  SYSCOMs  have  established  specific  mission  areas  for  each 
field  activity.  These  laboratory  mission  areas  are  described  on  the 
following  pages  and  in  more  detail  NAVMATINST  5450.27  and  the  DON  RDT&E 
Management  Guide,  NAVSO  P-2457.  The  time  required  for  arriving  at 
technological  decisions  can  be  significantly  reduced  by  drawing  on  these 
experienced  field  activity  resources. 

The  Navy  laboratory  team  should  be  designated  as  early  as  possible 
in  the  program  and  should  have  its  assignments  of  responsibility  and 
delegations  of  authority  defined  at  the  outset.  The  laboratories  should 
be  major  contributors  to  program  management  decisions  that  require 
technical  review  and  assessment.  Planning  the  role  of  the  laboratories 
should  be  done  on  a  program-life-cycle  basis  and  permit  the  laborato¬ 
ries  to  select  the  best  team  members  and  the  most  stable  organization 
and  methodology  to  meet  the  program  short-term  and  long-term  needs.  The 
laboratories  are  a  part  of  the  Navy  technical  team,  capable  of  stimulat¬ 
ing  and  supporting  industry,  and  not  a  competitor  to  industry. 

Experience  has  indicated  that  PMs  are  frequently  unsure  of  how  to 
best  utilize  the  resources  of  the  Navy  in-house  R&D  centers/laboratories 
and  other  field  support  facilities.  This  section  will  discuss  their  use 
and  tasking.  Emphasis  is  placed  on  the  Navy  laboratories  because  of 
their  full-spectrum  capability  encompassing  personnel,  expertise,  and 
facilities  for  all  phases  of  the  acquisition  process.  They  would  typi¬ 
cally  be  the  first  of  the  support  organizations  used,  transferring 
duties  to  the  SYSCOM  field  activities  at  appropriate  times. 

The  Navy  laboratories  differ  from  industrial  organizations  in  that 

they: 
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1.  Have  no  profit  motive. 

2.  Are  not  so  directly  influenced  by  the  changing  demands  of  the 
marketplace. 

3.  Are  allowed  virtually  unlimited  governmental -control led-infor- 
mation  access. 

4.  Have  a  continued  close  relationship  with  the  Fleet. 

5.  Maintain  comprehensive  technology  base  in  assigned  areas. 

6.  Can  be  "brought  on  board"  quickly  and  easily  with  a  task 
statement. 

They  also  differ  from  universities  in  items  2  through  4.  The  labor¬ 
atory  personnel  are  actively  and  intimately  engaged  in  evolving  tech¬ 
nology  in  cooperation  with  universities  and  industry  and  thus  possess  a 
level  of  technical  leadership  not  usually  found  in  the  other  "in-house" 
organizations. 

The  laboratories  can  provide  the  PM  with  a  fast  response  to  unex¬ 
pected  problems  or  other  urgent  matters.  This  fast  response  capability 
as  a  function  of  both  the  speed  of  the  tasking  process  and  the  availa¬ 
bility  of  a  pool  of  scientists  and  engineers  with  expertise  in  all 
disciplines  of  science,  and  first-hand  knowledge  of  the  technology  base. 

Laboratories  provide  technical  assistance  to  PMs  in  the  planning  of 
system  development,  acquisition,  and  usage  phases,  and  during  the  execu¬ 
tion  of  those  phases.  Assistance  includes  hand-on  development,  and 
management.  Because  of  their  extensive  experience  in  the  acquisition 
process,  laboratory  input  to  the  Source  Selection  Board  is  essential  in 
the  Mission  Area  Analysis-Program  Initiation  Period. 

The  laboratories  provide  engineering  support  at  the  PM's  request 
during  the  Production  and  Deployment  Phase.  They  do  this  by  drawing  on 
their  broad  base  of  experience  with  similar  systems  in  order  to  solve 
production  problems,  particularly  during  the  start-up  period  when  a  new 
contractor  is  involved.  In  addition,  laboratories  ensure  a  disciplined 
approach  in  production  support  areas  such  as  configuration  control, 
reliability,  and  quality  assurance  by  closely  monitoring  the  contrac¬ 
tor's  efforts.  Once  systems  are  in  operat  on,  the  laboratories  can 
provide  support  (along  with  the  SYSCOM  support  facilities)  to  solve  in- 
service  problems  and  to  define  and  carry  forward  product  improvement 
programs  when  needed.  They  can  also  assist  the  PMs,  SYSCOMs,  and  sup¬ 
port  facilities  in  the  preparation  of  training  programs  and  the  planning 
of  logistic  support  programs. 

Perhaps  the  most  valuable  contribution  of  the  laboratories,  in  the 
initial  planning  stages,  is  that  they  are  in  a  position  to  evaluate 
information  gathered  from  all  operational  systems,  together  with  user 
reactions,  and  in  turn  apply  the  "lessons  learned"  to  advancements  in 
technology,  new  acquisitions,  operations,  and  support. 

The  nine  Chief  of  Naval  Material  (CNM)  R&D  centers,  along  with  the 
Naval  Research  Laboratory  (NRL),  the  Naval  Ocean  Research  and  Develop¬ 
ment  Activity  (NORDA)  and  the  Naval  Civil  Engineering  Laboratory  (NCEL), 
serve  as  the  Navy's  corporate  RDT&E  body  and  are  involved  in  many  phases 
of  the  acquisition  process  from  maintaining  the  technology  base  (re¬ 
search,  exploratory  development,  and  advanced  development  concepts)  to 


fleet  in-service  engineering  support.  Their  staffs,  which  maintain 
technical  expertise  and  leadership  in  relevant  scientific  and  technical 
areas,  as  well  as  specialized  facilities  and  test  and  evaluation  (T&E) 
capability,  are  ready  to  serve  the  needs  of  the  PM. 

The  CNM-managed  R&D  centers  are  specifically  tasked  under  NAVMAT- 
INST  5450.27  to  provide  support  to  PMs  during  the  formative  stages  and 
the  actual  design,  development,  T&E  of  new  advanced  developments,  en¬ 
gineering  developments,  and  operational  systems  developments.  In  addi¬ 
tion,  the  Technical  Director  of  the  cognizant  Center  may  be  called  upon 
at  Department  of  the  Navy  Systems  Acquisition  Review  Council  (DNSARC) 
milestone  meetings  to  give  an  independent  critique  of  technological 
risks  of  the  program.  In  particular,  the  Centers  are  expected  to  assist 
in  the  performance  of  the  following  functions,  as  assigned  by  the  spon¬ 
sor. 

1.  Provide  technical  direction  during  the  acquisition  process. 

2.  Prepare  and  critique  the  proposed  system  specifications  and 
the  scientific  and  technical  documentation  packages  that  must 
be  provided  to  industry  at  the  beginning  of  a  competition  or 
new  development  and  participate  in  the  contractor  selection 
process. 

3.  Assess  the  risks  of  alternative  approaches 

4.  Solve  specific  technical  and  engineering  problems  by  conduct¬ 
ing  parallel  in-house  efforts,  or  providing  technical  assis¬ 
tance  to  contractors. 

5.  Design  and  develop  selected  systems  and  subsystems. 

6.  Provide  technical  leadership  for  planning  and  overseeing  the 
integration  of  new  systems. 

7.  Help  prepare  T&E  plans. 

8.  Conduct  periodic  design  &  progress  reviews  of  work  in  process. 

9.  Transition  systems  to  production,  including  product  assurance 
and  production  support. 

10.  Establish  and  qualify  additional  sources  for  procurement. 

Federal  acquisition  policy  is  explicit  in  the  requirement  that  the 
PM  consider  ".. .the  optimal  use  of  Government  laboratories  in  furnishing 
technical  direction  to  the  contractors  during  system  development."  (0MB 
Circular  No.  A- 109.)  While  a  laboratory  may  serve  in  any  of  the  three 
roles  indicated  in  Figure  2-6,  the  preferred  role  and  the  one  that  most 
effectively  utilizes  the  laboratory  resources  is  that  of  technical 
manager  or  assistant  technical  manager. 

NAVMATINST  5450.27  also  states  that  PMs,  as  a  general  rule,  will 
designate  a  lead  activity  in  the  early,  formative  phases  of  each  advanc¬ 
ed  and  engineering  development  program,  to  support  and  assist  the  pro- 


FIGURE  2~6.  Alternative  Functions  of  a  Navy  Laboratory  in  the  PMO. 


gram  or  PM  The  Director  of  Naval  Laboratories  (DNL),  MAT-05  [DCNM(LM)] 
will  be  advised  of  proposed  exceptions  to  this  rule.  The  activity 
selected  as  lead  will  normally  be  the  one  with  the  greatest  expertise 
and  experience  in  the  area  involved  and  which  can  allocate  the  necessary 
resources  to  the  effort. 

The  specific  responsibilities  to  be  assigned  to  a  lead  activity  at 
any  given  time  in  the  RDT&E  process  will  be  determined  by  the  PM.  The 
mission  of  the  principal  centers/laboratories  are: 

1.  David  W.  Taylor  Naval  Ship  Research  and  Development  Center 
(DTNSRDC),  Bethesda,  Maryland.  DTNSRDC  is  the  principal  RDT&E  center 
for  naval  vehicles  and  logistics,  provides  RDT&E  support  to  the  U.S. 
Maritime  Administration  and  the  maritime  industry. 

2.  Naval  Air  Development  Center  (NADC),  Warminster,  Pennsylvania. 
NADC  is  the  principal  Navy  RDT&E  center  for  naval  aircraft  systems  less 
aircraft- launched  weapon  systems. 

3.  Naval  Civil  Engineering  Laboratory  (NCEL),  Port  Hueneme,  Cali¬ 
fornia.  NCEL  is  the  principal  Navy  RDT&E  laboratory  for  shore  facili¬ 
ties,  fixed  surface  and  subsurface  ocean  facilities  and  for  the  Navy  and 
Marine  Corps  construction  forces. 

4.  Naval  Coastal  System  Center  (NCSC),  Panama  City,  Florida. 
NCSC  is  the  principal  Navy  RDT&E  Center  for  mine  and  undersea  warfare, 
diving  and  other  naval  missions  that  take  place  primarily  in  the  coastal 
regions. 


5.  Naval  Ocean  Research  and  Development  Activity  (NORDA),  Bay  St. 
Louis,  Mississippi.  NORDA  is  the  principal  Navy  RDT&E  activity  for 
ocean  science  and  technology,  with  emphasis  on  understanding  ocean 
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processes  through  measurement  and  analysis,  and  the  effects  of  the  ocean 
environment  on  Navy  systems  and  operations. 

6.  Naval  Ocean  Systems  Center  (NOSC),  San  Diego,  California. 
NOSC  is  the  principal  Navy  RDT&E  center  for  command  control,  communica¬ 
tions,  ocean  surveillance,  surface-  and  air-launched  undersea  weapon 
systems  and  submarine  arctic  warfare. 

7.  Navy  Personnel  Research  and  Development  Center  (NPRDC),  San 
Diego,  California.  NPRDC  is  the  principal  Navy  RDT&E  center  for  man¬ 
power,  personnel,  education,  training  and  human  factors,  and  for  pro¬ 
viding  technical  support  to  the  CNO  in  these  areas. 

8.  Naval  Research  Laboratory  (NRL),  Washington  D.C.  NRL  conducts 
broadly  based  multi-disciplinary  program  of  scientific  research  and 
advanced  technological  development  directed  toward  new  and  improved 
materials,  equipment,  techniques,  systems  and  related  operational  proce¬ 
dures  for  the  Navy. 

9.  Naval  Surface  Weapons  Center  (NSWC),  Dahlgren,  Virginia.  NSWC 
is  the  principal  Navy  RDT&E  center  for  surface  ship  weapon  systems, 
ordnance,  mines,  and  strategic  systems  support. 

10.  Naval  Training  Equipment  Center  { NTEC ) ,  Orlando,  Florida. 
NTEC  conducts  RDT&E  and  procurement  of  training  equipment,  systems, 
devices,  simulators,  and  aids. 

11.  Naval  Underwater  Systems  Center  (NUSC),  Newport,  Rhode  Island. 
NUSC  is  the  principal  RDT&E  center  for  submarine  warfare  and  submarine 
weapon  systems. 

12.  Naval  Weapons  Center  (NWC),  China  Lake,  California.  NWC  is 
the  principal  Navy  RDT&E  canter  for  air  warfare  systems  (except  ASW 
systems)  and  missile  weapon  systems  and  the  national  range/facility  for 
parachute  test  and  evaluation. 

One  of  the  distinct  advantages  of  the  in-house  Navy  RDT&E  facili¬ 
ties  is  the  ease  with  which  they  can  be  tasked  and  hence  the  ease  which 
work  can  be  initiated  or  halted.  Tasking  through  work  unit  as¬ 
signment  varies  slightly  from  SYSCOM  to  SYSCOM  but  the  procedures  are 
well  established  and  simple.  Face-to-face  discussions  are  held  to 
determine  exactly  what  the  PM  wants  done  and  the  responsibility  to  be 
assigned.  Unlike  contractual  obligations  negotiated  with  industry, 
changes  can  be  readily  made  without  the  time-consuming  planning  and 
negotiating  normally  associated  with  Request  For  Proposals  (RFPs),  Re¬ 
quest  for  Authority  to  Negotiate  (RANs),  Determination  and  Findings 
(D&Fs) ,  etc.  Since  both  the  PM  and  the  RDT&E  facility  are  motivated  by 
a  desire  to  accomplish  Navy  goals,  there  are  considerably  less  grounds 
for  disagreement  than  in  PM/contractor  dealings. 

Because  of  imposed  personnel  ceilings  and  the  requirements  for  the 
R&Q  centers  to  accept  new  R&Q  assignments  and  maintain  a  balanced  work¬ 
load,  it  may  be  necessary  for  them  to  transition  work  to  the  specialized 
SYSCOM  field  activities  at  appropriate  stages  of  development.  Transfer 
is  typically  initiated  near  the  end  of  full-scale  development  (FSD)  and 
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completed  after  the  first  full-volume  production.  It  is  essential  for 
the  PM  to  allow  and  encourage  such  transfer. 

The  various  SYSCOM  field  activities  and  T&E  facilities  also  play 
vital  support  roles  in  the  development,  test,  and  evaluation  of  new 
systems.  Unlike  the  CNM  R&D  centers,  the  SYSCOM  field  stations  typical¬ 
ly  are  not  full-spectrum  activities  but  are  more  highly  specialized  with 
expertise  in  the  support  of  fielded  systems.  Like  the  CNM  R&D  centers, 
they  may  be  easily  tasked  by  the  PM  to  provide  the  amount  of  support 
needed  in  the  particular  area  of  specialization. 

Representative  SYSCOM  field  activities  and  T&E  facilities: 

1.  Atlantic  Undersea  Test  and  Evaluation  Center  (AUTEC),  West 
Palrr.  Beach,  Florida.  AUTEC  provides  a  deepwater  T&E  facility  for  ship, 
sensor,  and  underwater  weapons  systems. 

2.  Atlantic  Fleet  Weapons  Training  Facility  (AFWTF),  Roosevelt 
Roads,  Puerto  Rico.  AFWTF  supports  development  and  testing  of  ship  and 
air  weapons  systems  and  fleet  training. 

3.  Marine  Corps  Development  and  Education  Command  (MCDEC),  Quanti- 
co,  Virginia.  MCDEC  performs  RDT&E  for  Marine  Corps  doctrine  and  equip¬ 
ment. 


4.  Naval  Air  Engineering  Center  (NAEC),  Lakehurst,  New  Jersey. 
NAEC  conducts  RDT&E  for  aircraft  launching  and  recovery  support  systems 
and  ground  support  equipment, 

5.  Naval  Air  Propulsion  Center  (NAPC),  Trenton,  New  Jersey.  NAPC 
performs  T&E  of  aircraft  propulsion  systems. 

6.  Naval  Air  Test  Center  (NATO,  Po'-'jxent,  Maryla  .  NATC  per¬ 
forms  T&E  of  aircraft  and  weapons  systems  and  ground  suppoi  equipment. 

7.  Naval  Avionics  Center  (NAC),  Indianapolis,  Indiana.  NAC  con¬ 
ducts  R&D,  acquisition,  and  integrated  logistics  support  on  airborne 
electronics,  missiles  and  weapon  systems  and  equipment. 

8.  Naval  Ordnance  Station  (NOS/IH)  Indianhead,  Maryland.  NOS/IH 
provides  material  and  technical  support  for  weapon  systems,  weapons,  and 
components  as  directed  by  the  Commander,  Nuval  Sea  Systems  Command. 

9.  Naval  Ship  Weapon  Systems  Engineering  Station  (NSWSES),  Port 
Hueneme,  California.  NSWSES  conducts  T&E  of  developmental  and  upgraded 
combat  and  weapon  systems  for  surface  combatants.  It  is  also  the  In- 
Service  Engineering  Agent  for  surface  Navy  AAW  and  ASUW  systems. 

10.  Naval  Weapons  Support  Center  (NWSC/C),  Crane,  Indiana.  NWSC/C 
provides  material,  technical  and  logistics  support  for  ships  and  crafts 
equipment,  shioboard  weapon  systems,  and  expendable  and  non-expendable 
ordnance  items  (principal  Navy  RDT&E  for  pyrotechnics). 

11.  Naval  Weapons  Evaluation  Facility  (NWEF) ,  Albequerque,  New 
Mexico.  NWEF  performs  T&E  and  provides  technical  support  for  nuclear 


and  special  weapons  systems. 


12.  Pacific  Missile  Test  Center  (PMTC),  Point  Mugu,  California. 
PMTC  provides  range  facilities,  RDT&E,  and  support  for  DOD  missile, 
satellite,  and  space  vehicle  programs. 


Commander,  Operational  Test  and  Evaluation  Force  (COMOPTEVFOR) . 
For  ACAT  I,  II,  III,  and  IVT  programs,  for  which  a  TEMP  and  operational 
testing  is  required,  early  coordination  with  COMOPTEVFOR  is  advantageous 
and  strongly  recommended.  As  the  Navy's  independent  agent  for  opera¬ 
tional  test  and  evaluation  (OT&E),  COMOPTEVFOR  is  charged  in  OPNAVINST 
5440.47  with: 

o  Reviewing  the  test  and  evaluation  (T&E)  planning  for  new 

weapons  systems  and  reporting  to  CNO  on  the  adequacy  of  the 
plan  to  address  and  resolve  critical  issues 

o  Evaluating  the  operational  effectiveness,  suitability,  and 

capability  of  tested  weapon  systems  to  meet  stated  needs  and 
performance  criteria 

o  Developing  tactics  and  procedures  for  the  employment  of  speci¬ 
fic  weapons  systems 

It  is  essential  that  COMOPTEVFOR  be  involved  in  the  acquisition 
program  early  in  order  to  carry  out  these  responsibilities.  This  early 
involvement  can  be  of  great  assistance  to  the  PM  as  COMOPTEVFOR* s  expe¬ 
rience  provides  an  invaluable  source  of  information  concerning  program 
structure,  dos  and  donts,  and  both  general  and  detailed  planning. 


Contract  Support  Services 

Often  a  PM  finds  it  necessary  to  contract  for  consulting  services, 
studies,  or  ocher  professional  and  management  support  services  not 
available  through  his  staff,  SYSCOM,  or  supporting  field  activity. 
SECNAVINST  4860. 44C  (Commercial  and  Industrial  Activities)  establishes 
Navy  policy  of  relying  on  the  private  enterprise  system  to  the  maximum 
extent  that  such  reliance  promotes  effective  accomplishment  of  essential 
programs.  Care  is  required,  however,  to  ensure  that  contract  support 
services  are  not  used  to  contract  for  personal  services  not  authorized 
by  law,  or  to  circumvent  competitive  civil  service  procedures  and  Clas¬ 
sification  Act  pay  limits. 

In  the  past,  several  nonpersonal -service  contracts  have  been  ruled 
illegal  or  have  come  under  congressional  scrutiny.  As  a  result,  the  Of¬ 
fice  of  Personnel  Management  and  Comptroller  General  have  issued  sever¬ 
al  decisions  which  state,  in  essence,  that  the  proper  use  of  nonpersonal 
contract  support  services  involves  meeting  two  conditions:  the  contract 
must  ask  for  the  finished  product,  and  the  contract  must  be  administered 
in  such  a  way  that  control  and  supervision  over  the  work  and  the  discre¬ 
tion  as  to  the  techniques  used  remain  solely  with  the  contractor.  The 
Navy  has  also  issued  amplifying  instructions  to  enable  more  effective 
use  of  contract  support  service  and  to  prevent  their  misuse. 


SECNAVI NST  4200.27  (“Contract  Support  Services:  Planning  and  Ad¬ 
ministration'1}  was  issued  to  ensure  that  all  Navy  personnel  having 
responsibilities  related  to  contracts  for  support  services  understand 
the  limitations  upon  the  use  of  such  contracts,  the  difference  between 
personal  and  nonpersonal  services,  and  the  factors  that  may  render 
otherwise  proper  contacts  illegal. 

NAVMATINST  4200.50  ("Use  of  Contractor  Support  Services")  was  issu¬ 
ed  to  ensure  that  use  of  commercial  sources  to  supplement  internal 
resources  in  the  planning,  conduct,  and  evaluation  of  assigned  missions 
and  related  programs  does  not  compromise  or  weaken  the  Navy's  fundament¬ 
al  responsibility  for  controlling  and  managing  Navy  programs.  A  partial 
listing  of  specific  work  that  should  not  be  performed  under  contract 
includes  program  planning,  budgeting,  and  fund  allocation  (for  example, 
preparation  or  maintenance  of  budgets);  military,  business,  and  acquisi¬ 
tion  strategy  planning  (for  example,  preparation  of  POM's);  and  contract 
negotiation  and  award  (for  example,  preparation  of  business  clearances). 

Legal  review  and  Flag  or  Senior  Executive  Service  (SES)  approval 
are  required  only  when  obligations  will  total  more  than  $50,000.  A 
review  by  counsel  of  those  requirements  under  $50,000  may  be  requested 
when  appropriate.  Contract  obligations  of  more  than  $25,000  must  be 
reviewed  by  counsel  for  nonpersonal -services  determination.  If  the 
contract  award  is  noncompetitive,  and  the  estimated  total  dollar  value 
exceeds  $1  million,  approval  by  the  DON  Oversight  Manager  (MAT-02B)  is 
required. 


Section  3 


THE  ACQUISITION  PROCESS 


PROGRAM  INITIATION 
Mission  Area  Analysis  (MAA) 

MAA,  technology  base  development,  internal  political  influences  and 
the  mission  need  determination  lead  to  program  initiation.  Although 
these  factors  collectively  are  not  considered  as  a  phase  of  the  acquisi¬ 
tion  process,  and  though  they  occur  prior  to  the  designation  of  a  pro¬ 
gram  manager  (PM),  it  is  important  that  the  PM  understand  their  nature 
and  scope. 

DOD  Directive  (DODD)  5000.1  cites  analysis  of  mission  areas  as  a 
means  for  the  services  to  identify  deficiencies  or  opportunities  that 
could  lead  to  the  initiation  of  a  major  systems  acquisition  program. 
The  Navy,  however,  does  not  routinely  carry  out  such  analysis.  More 
typically,  0P-095/090  will  carry  out  analyses  at  the  request  of  the 
Chief  of  Naval  Operations  (CNO)  or  if  requested  by  sponsors  for  a  pro¬ 
gram  in  which  they  are  interested  and  for  which  they  are  willing  to 
spend  their  limited  dollars.  Hence  much  of  the  initial  MAA  Is  carried 
out  by  Navy  Research  and  Development  (R&D)  centers  or  by  industry  as 
part  of  independent  research  and  exploratory  development  programs. 


Basic  Requirements  for  a  New  Start 

The  basic  requirements  for  the  start  of  a  new  acquisition  program 
are  a  program  initiation  document  and  the  allocation  of  funds. 

The  program  initiation  document  identifies  a  specific  deficiency  in 
the  mission  area,  the  relative  priority  assigned  to  correcting  the 
deficiency,  and  an  estimate  of  the  magnitude  of  resources  necessary  to 
correct  the  deficiency.  Unlike  operational  requirements  documents  of 
the  past,  which  tended  to  describe  general  requirements,  the  program 
initiation  document  should  define  the  deficiency  as  narrowly  as  possible 
so  that  there  is  a  reasonable  probability  of  correcting  it  by  developing 
a  single  system.  However,  solutions  to  the  problem  should  not  be  speci¬ 
fied. 


Approval  of  the  program  initiation  document  -  included  along  with 
the  Program  Objectives  Memorandum  (POM)  submittal  in  the  Planning, 
Programming,  Budgeting  System  (PPBS)  -  constitutes  permission  to  move 
ahead  into  the  Concept  Exploration  Phase  once  money  has  been  appropriat¬ 
ed  or  reprogrammed .  The  requirement  to  include  the  new  start  within  a 
constrained  Navy  budget  (thereby  subjecting  it  to  the  inevitable  com¬ 
petition  for  funds)  strongly  influences  the  program  initiation  process. 

It  is  probable  that  during  the  course  of  preparing  the  proposed 
program  initiation  document  and  getting  it  approved,  compromises  and 
changes  were  made  in  the  proposed  document.  While  this  process  may  take 
place  before  the  PM's  "watch",  he  should  find  out  and  document  these 
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compromises  and  changes  so  that  previously  resolved  issues  will  not  be 
resurrected  whenever  a  new  PM  appears  on  the  scene.  He  should  also  know 
where,  in  the  in-house  R&D  laboratory/center  and  industrial  communities, 
the  technical  expertise  has  been  developed  and  what  other  programs  and 
funding  claimants  are  competing  for  the  same  fiscal  and  manpower  sup¬ 
port.  MAT-05  can  provide  assistance  to  the  program  manager  (PM)  in 
selection  of  the  development  lead  laboratory. 


Documentation  Requirements  for  Program  Initiation 

There  are  five  documents  used  by  the  Department  of  the  Navy  (DON) 
during  the  program  initiation  process;  they  are: 

Tentative  Operational  Requirement  (TOR).  The  TOR  describes  a  need 
for  a  new  system  as  perceived  by  the  Office  of  the  Chief  of  Naval 
Operations  (OPNAV).  The  TOR  describes  the  desired  capability  in  general 
terms.  When  numbers  are  used  they  are  to  be  in  broad  ranges.  The  TOR 
is  limited  to  three  pages.  See  OPNAVINST  5000. 42B  for  the  required  TOR 
format. 

Development  Options  Paper  (POP).  The  DOP  is  a  Naval  Material 
CommanH  (NaVMaT)  reply  to  a  TOR  and  is  based  on  the  exploration  of 
options.  The  DOP  describes  a  range  of  possible  systems  covering  a 
spectrum  of  capabilities.  The  DOP  should  be  as  short  as  possible  with 
the  TOR  appended.  See  OPNAVINST  5000. 42B  for  the  required  DOP  format. 

Operational  Requirement  (OR).  The  OR  describes  the  major  charac- 
teri sties  of  the  alternative  selected  by  the  OPNAV  sponsor,  as  a  result 
of  the  review  of  the  DOP,  which  best  matches  the  desired  capabilities 
within  affordability  limitations.  The  OR  is  limited  to  three  pages. 
See  OPNAVINST  5000. 42B  for  the  required  OR  format. 

Required  Operational  Capability  (ROC).  The  ROC  is  used  to  document 
a  Marine  Corps  need  and  is  a  brief  statement  of  a  specific  operational 
capability.  See  Marine  Corps  Order  (MCORD)  3900.4  for  the  required  ROC 
format. 

Justification  for  Major  System  New  Start( JMSNS) .  The  JMSNS  serves, 
for  major  systems,  the  same  purpose  as  the  OR  and  ROC  do  for  other-than- 
major  systems.  The  JMSNS  is  limited  to  three  pages.  See  DOD  Instruction 
(DODI)  5000.2  for  the  required  JMSNS  format. 


Influences  on  the  Program  Initiation  Document 

Development  of  a  JMSNS,  OR,  or  ROC  is  influenced  by  other  factors. 
Among  these  are  the  effects  of  technical  innovation,  the  evolution  of 
the  document  within  OPNAV,  and  the  competition  for  funds  within  the 
PPBS. 

Technical  Innovations.  During  a  period  which  may  cover  several 
budget  cycles,  advanced  system  and  building-block  concepts  are  evolved 
either  by  Navy-  and  DOD-sponsored  research  and  technology  programs  or 
independently,  by  industry  and  academia.  These  concepts  may  form  the 


technology  drivers  for  a  JMSNS,  OR,  or  ROC. 

The  typical  route  for  major  development  proposals  has  been  for  the 
entrepreneur  (in  government  or  industry)  to  convince  the  responsible 
office  within  NAVMAT  or  a  Systems  Command  (SYSCOM),  or  an  OPNAV  sponsor, 
of  the  value  of  the  advanced  concept  and  the  desirability  of  direct 
funding  prior  to  submittal  of  the  need  document.  As  a  result,  a  line 
item  {6  3A)  may  be  established  in  the  Five-Year  Defense  Program  (FYDP) 
to  fund  the  further  technological  advances  necessary  to  develop  the 
concept,  to  conduct  in-depth  analysis  of  its  utility,  and/or  to  conduct 
technical  demonstrations  of  the  concept.  More  often,  Funding  for  this 
work  is  provided  within  an  appropriate  existing  program  element. 


Advanced  Development  Project  Office  (ADPO) 

Frequently,  an  ADPO  and  team  is  established  within  the  appropriate 
System  Command  (SYSCOM)  office  to  coordinate  and  manage  the  effort,  as 
in  the  example  shown  in  Figure  3-1  on  the  next  page.  The  program 
officer  in  charge  is  thus  in  a  position  to  assist  the  OPNAV  sponsor  in 
writing  the  appropriate  requirements  document  and  processing  it  through 
the  approved  chain.  Often  the  program  officer  will  rely  completely  on 
the  existing  SYSCOM  structure  and  the  in-house  R&D  laboratories/centers, 
coordinated  through  a  lead  R&D  center,  for  the  technical  support  and 
technical  management  of  the  major  contracts.  This  is  particularly  advis¬ 
able  if  the  lead  laboratory/center  has  been  involved  in  creating  the 
technology  base  upon  which  the  system  concept  is  founded.  An  advantage 
of  the  ADPO  is  that  the  skeleton  of  a  program  management  office  (PMO)  is 
already  set  up  and  working  by  the  time  the  program  initiation  document 
Is  approved  and  the  program  manager  (PM)  is  formally  appointed  and 
chartered. 


Program  Initiation  Document  Evolution  within  OPNAV.  The  process  by 
which  a  JmSNs,  or  ROC  is  generated  within  the  OPNAV  is  shown  in 
Figure  3-1.  A  simple  diagram,  however,  cannot  convey  the  fact  that  both 
OPNAV  and  the  larger  DOD  organization  within  which  it  operates  are 
composed  of  people  with  varying  degrees  of  strength,  influence,  inte¬ 
rest,  and  efficiency.  The  path  leading  to  the  proposed  JMSNS/OR/ROC  in 
a  given  program  may  not  have  touched  all  the  functional  units  shown  here 
-  some  being  more  critical  than  others. 

The  phrase  "other  influences"  in  Figure  3-1  represents  a  host  of 
organizations  and  forces  that  bear  upon  the  preparation  of  a  JMSNS/OR/ 
ROC  Among  these  are  the  Secretary  of  the  Navy  (SECNAV),  the  Office  of 
the  Secretary  of  Defense  (OSD),  the  Organization  of  the  Joint  Chiefs  of 
Staff  (OJCS),  industry,  the  North  Atlantic  Treaty  Organization  (NATO) 
interests,  and  Congress.  The  strength  of  a  particular  organization's 
influence  will  depend  on  the  existence  within  that  organization  of  a 
powerful  advocate  with  a  strong  voice. 

It  is  useful  for  the  PM  to  know  the  supporter  of  his  program  at 
every  level  since  their  continued  support  is  vital  to  the  program.  If 
the  PM  will  ensure  that  these  supporters  are  at  all  times  appraised  of 
the  program  status,  he  will  likely  enjoy  their  continuing  support.  Some 
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care  must  .be  taken  in  how  the  information  flow  from  PM  to  his  supporters 
is  maintained.  The  Navy  requires  that  contacts  with  offices  and  person¬ 
nel  in  OSD  be  made  through  the  program  coordinator  or  development  coor¬ 
dinator  in  OPNAV,  and  that  contacts  with  Congress  be  carried  out  only 
throuqh  the  Congressional  liaison  office.  Although  assignment  as  a  PM 
does  not  remove  one's  constitutional  right  to  speak  to  his  representa¬ 
tive  or  senators  in  Congress,  such  contacts  (when  they  reflect  on  his 
program)  should  be  made  with  extreme  caution  and  preferably  with  the 
advance  knowledge  of  superiors  and  sponsors.  End  runs  around  the 
system,"  while  sometimes  effective,  can  also  backfire  and  ruin  a  career. 


Joint  Service  Programs 

Joint  service  programs  are  instituted  for  operational  and/or  eco¬ 
nomic  reasons,  e.g.,  simplification  of  logistic  operations  or  improve¬ 
ment  of  combat  capability.  They  are  strongly  supported  and  encouraged 
by  OSD  and  Congress.  Rarely  are  acquisition  programs  joint  from  their 
inception  and  few  programs  become  joint  without  some  initiative  by  the 
Secretary  of  Defense  (SECDEF)  or  the  Congress.  Most  are  preceded  by 
individual  service  efforts,  often  after  much  R&D  has  been  accomplished. 

Typically,  the  Under  Secretary  of  Defense  for  Research  and  Engin¬ 
eering  (USDR&E)  will  write  a  memorandum  designating  one  service  as  the 
lead  (or  executive)  service  and  directing  it  to  charter  a  joint  program 
office.  The  services  negotiate  the  ground  rules  of  the  joint  program 
and  aqree  to  assignments  of  program  authority,  responsibility,  ana 
funding.  When  a  decision  is  made  to  initiate  a  joint  service  program  as 
as  result  of  an  approved  JMSNS,  designation  of  the  lead  service  is  made 
by  the  SECDEF  in  a  SECDEF  Decision  Memorandum  (SDDM) . 

Interservice  negotiation  and  agreement  on  a  joint  program  may  occur 
at  any  one  of  several  echelons:  the  service  secretariats,  the  service 
headquarters,  the  material  development  and  logistics  commands,  or  their 
commodity-oriented  subcommands.  Interservice  agreements  are  normally 
made  between  organizations  of  the  same  level. 

There  are  two  advantages  to  agreements  at  the  service  headquarters 
level.  First,  it  is  the  level  at  which  operational  needs  are  validated 
and  translated  into  equipment  needs.  Second,  it  is  the  1e^  *t  whi.h 
funding  priorities  are  established.  Nothing  is  more  important  to  the 
success  of  a  joint  program  than  interservice  agreement  on  needs  and 
funding.  The  major  disadvantage  of  inter-headquarters  agreements  is  the 
length  of  time  required  for  staff  consideration. 

Agreement  at  either  the  service  headquarters  or  secretariat  level 
is  usually  documented  by  a  memorandum  of  agreement  (MOA).  There  is  no 
typical  format  for  an  MOA.  It  may  define  all  the  ground  rules  for  the 
joint  program,  much  as  a  charter  would,  or  it  may  be  brief,  cohering 
only  key  areas  of  agreement.  Frequently,^  a  program  will  have  several 
MOAs  associated  with  it,  each  covering  a  different  topic. 

The  basis  for  joint  programs  is  DODI  5000.2  and  a  MOA  signed  by  the 
Joint  Logistic  Corrmanders  in  1973  (Management  of  Multi-Service  Systems/ 
Projects/Programs,  NAVMATINST  5000. 1A).  For  a  comprehensive  study  of 
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joint  program  management,  the  reader  is  directed  to  the  Joint  Logistics 
Commanders'  Guide  to  the  Management  of  Joint  Service  Programs,  published 
by  Defense  Systems  Management  College,  Fort  Belvoir,  Virginia  22060. 


NATO  Standardization  and  Interoperability  &  Foreign  Military  Sales  (FMS) 


Two  other  factors  may  strongly  influence  the  MND  and  the  subsequent 
system  acquisition:  requirements  by  DOD  and  DON  for  achieving  standardi¬ 
zation  and  interoperability  of  weapons  and  equipment  within  the  NATO, 
and  the  Security  Assistance  Program,  especially  foreign  military  sales 
(FMS).  SECNAVINST  5000.1  provides  direction  that  consideration  must  be 
given  to  NATO  rationalization,  standardization  and  interoperability 
(RSI),  as  well  as  reciprocal  procurement  or  offset  agreements  with 
friendly  foreign  countries.  Further,  detailed  requirements  for  NATO  RSI 
are  given  in  DODD  2010.7  and  DODD  2010.6  as  well  as  SECNAVINST  5711.10. 
The  PM  should  note  that  NATO  RSI  must  be  considered  during  the  acquisi¬ 
tion  process  and  addressed  at  each  acquisition  milestone. 


Security  assistance  provided  to  foreign  countries  by  the  U.S. 
consists  of  international  military  education  and  training  (IMET),  grant 
aid,  and  military  export  sales.  Sales  are  either  commercial  (direct 
procurements  by  a  foreign  country  from  U.S.  private  sources)  or  FMS 
(sales  by  the  U.S.  government  to  a  foreign  government).  Both  FMS  and 
commercial  sales  may  include  licensing,  co-production,  or  offset  ar¬ 
rangements.  Specific  responsibilities,  policies,  and  procedures  are  set 
forth  in  DOD  5105. 38M,  Military  Assistance  and  Sales  Manual  (MASM). 
This  manual  is  the  principle  source  of  information  and  instructions  for 
administering  the  U.S.  military  assistance  and  FMS  programs.  Additional 
guidance  is  set  forth  in  NAVMATNST  4900.22,  the  Naval  Material  Command 
Security  Assistance  Program  and  Support  Planning  Manual.  While  pros¬ 
pects  for  FMS  can  affect  a  program's  initiation  and  provide  some  funding 
for  R&D,  its  greatest  impact  usually  occurs  after  major  development  has 
been  accomplished  and  the  program  is  ready  to  enter  into  production. 
Security  assistance  programs  have  their  own  funding,  configuration  con¬ 
trol,  quality  assurance  problems,  etc.,  as  well  as  their  own  reporting 
channels  from  SYSCOMs  through  to  the  Assistant  Secretary  of  Defense  for 
International  Security  Affairs  [ASA(ISA)],  One  of  the  principle  advan¬ 
tages  accrued  to  the  program  and  the  U.S.  is  the  reduction  in  unit  costs 
during  production  as  a  result  of  larger  buys  than  can  be  supported  by 
the  Navy  or  DOD  alone. 


Formal  Process.  Figure  3-3  on  the  next  page  illustrates  how  a 
Navy-oriented  JMSNS/0R  is  conceived  and  staffed  through  the  system.  The 
staffing  of  the  JMSNS  and  OR  differs  primarily  on  the  level  of  review 
required  and  who  signs  off  or  approves  the  program. 


Guidance  from  the  SECDEF,  the  Joint  Chiefs  of  Staff  (JCS),  intelli¬ 
gence  sources,  as  well  as  inputs  from  the  Fleet,  are  provided  to  the 
Fleet  commanders,  OPNAV  sponsors,  and  acquisition  managers  in  OPNAV  and 
NAVMAT.  The  information  is  used  to  gauge  needs,  capabilities,  and 
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FIGURE  3-3.  Preparing  the  Program  Initiation  Document. 


ongoing  developments  in  the  Navy  mission  areas  in  order  to  assess  speci¬ 
fic  unfulfilled  operational  needs. 

These  needs  are  presented  to  OPNAV,  which  conducts  MAA  and,  if  a 
need  is  substantiated  by  the  analysis,  the  OPNAV  sponsor  prepares  a  TOR 
and  transmits  it  to  NAVMAT.  The  TOR  describes  the  need  (desired  capa¬ 
bilities)  in  general  terms. 

In  reply  to  the  TOR,  the  cognizant  SYSCOM  develops  a  DOP  which  is 
coordinated  and  distributed  by  NAVMAT.  The  DOP  outlines  a  complete  menu 
of  systems,  from  those  of  minimum  capability,  cost,  and  time  -  including 
upgrades  of  existing  systems  -  to  advanced  systems  of  great  capability 
and  cost,  with  much  later  initial  operational  capability  (IOC). 

The  OPNAV  sponsor  selects  the  alternative  to  be  pursued  and  origin¬ 
ates  a  OMSNS/OR.  If  the  alternative  chosen  is  determined  to  represent  a 
major  system  (Acquisition  Category  (ACAT)  I  program),  OPNAV  documents 
that  need  in  a  JM.SNS.  The  OJCS  and  OSD  may  also  prepare  the  JMSNS  in  DON 
mission  areas.  If  the  need  is  estimated  to  represent  a  program  other 
than  ACAT  I  (i.e.,  an  ACAT  IIS,  IIC,  III,  or  IV),  OPNAV  documents  the 
need  in  an  OR.  Marine  Corps  needs  are  treated  in  a  similar  fashion 
with  staffing  done  within  Marine  Corps  Headquarters  with  assistance  from 
the  Marine  Corps  Development  and  Education  Center  (MCDEC),  the  SYSCOMs, 
and  OPNAV.  Documentation  for  Marine  Corps  programs  is  similar,  i.e., 
OMSNS  for  ACAT  I  programs  and  a  ROC  for  all  other  ACATs. 


Informal  Process.  The  actual  manner  in  which  a  new  program  is 
started  often  differs  from  the  formal  process  described.  For  example: 
as  part  of  an  in-house  technology  base  program  (or  an  aerospace  firm's 
independent  research  and  development  ( IR&D )  program),  a  Chief  of  Naval 
Material  ( CNM) -commanded  R&D  center  determines  that  a  new  anti-air 
missile  is  both  feasible  and  desirable.  The  first  step  is  to  find  an 
advocate  within  the  appropriate  OPNAV  sponsoring  code,  e.g.,  0P-05  for 
an  air-launched  system.  It  is  well  to  have  first  enlisted  support  for 
the  new  missile  within  the  appropriate  supporting  SYSCOM. 

Someone  in  the  sponsor's  code  (perhaps  with  assistance  from  the 
center/entrepreneur)  will  need  to  prepare  a  POM  issue  paper  covering  the 
proposed  new  start.  The  paper  will  include  an  abbreviated  (one  page) 
version  of  the  proposed  need  document  and  describe  what  the  new  system 
is  supposed  to  do,  the  threat,  existing  systems  to  be  replaced,  the 
approximate  costs  of  the  system,  and  the  amount  on  money  required  for 
the  Five  Year  Defense  Program  (FYDP)  period. 

This  issue  paper  is  then  reviewed  within  the  OPNAV  sponsor's  group 
to  determine  whether  the  proposed  system  is  affordable,  where  the  needed 
money  can  be  obtained  [i.e.,  at  the  expense  of  what  other  program(s)], 
and  what  the  relative  priority  of  the  program  should  be  within  the  gamut 
of  programs  being  sponsored. 

The  sponsor  (with  assistance  of  OP-501  in  this  case)  then  prepares 
a  Sponsor  Program  Proposal  (SPP)  and  a  Mini -MI P  (a  short  version  of  a 
Navy  RDT&E  Management  Information  Paper),  the  latter  prepared  jointly  by 
OP-982  and  the  appropriate  sponsor  in  0P-05.  The$°  steps  are  necessary 
both  for  a  program  to  be  added  to  an  existing  program  and  for  initiating 
a  completely  new  program.  Once  these  steps  have  been  completed,  the 
proposed  new  start  is  processed  like  any  other  POM  submittal.  A  TOR, 
OOP  and  OR  would  be  prepared  later  after  the  concept  feasibility  had 
been  proven. 


Program  Initiation  Review  and  Approval 

Each  phase  of  a  Navy  acquisition  program  is  subject  to  one  or  more 
reviews  by  successively  higher  echelons  before  the  designated  PDA  ren¬ 
ders  a  decision.  The  purpose  of  phase  review  is  twofold.  First,  it 
ensures  that  all  areas  of  uncertainty  (need,  technical,  fiscal)  are 
carefully  considered  and  evaluated  before  a  commitment  is  made  to  pro¬ 
ceed  to  the  next  phase.  Second,  it  gives  the  review  and  PDAs  the 
opportunity  to  make  sure  that  the  mission  need  Is  still  valid  and  that 
the  program  initiation  document  accurately  reflects  the  organizational 
view  of  the  need.  Appendix  A  provides  a  step-by-step  description  of  the 
program  initiation  process. 

The  JMSNS/OR  is  routed  via  0P-01,  0P-04,  and  0P-090,  approved  by 
OP-095  (0P-Q6  for  strategic  nuclear  systems)  and  promulgated  by  OP-098. 
High-cost  or  controversial  programs  will  be  concurred  in  by  CNO/Vice 
Chief  of  Naval  Operations  (VCNO)  prior  to  approval  of  the  OMSNS/OR.  0P- 
090  will  decide  whether  this  is  accomplished  by  the  CNO  Executive  Board/ 
Acquisition  Review  Committee/5hip  Characteristics  and  Improvement  Board 
(CEB/ARC/SCIB)  or  directly  by  OP-095(OP-06) . 


3-8 


Once  the  program  initiation  document  has  been  approved,  it  is 
incorporated  by  QPNAV/HQMC  as  a  line  item  in  the  next  DON  POM.  Approval 
of  the  proposed  POM  by  the  CNO  or  CMC  provides  the  program  start  deci¬ 
sion,  endorses  the  OR  or  ROC,  and  allows  an  ACAT  IIC,  III  or  IV  program 
to  enter  the  Concept  Exploration  Phase  after  budget  approval. 

The  proposed  POM  is  then  submitted  to  the  SECNAV  for  review  and 
approval.  Approval  of  the  POM  with  a  line  item  representing  an  ACAT  IIS 
program  endorses  the  OR  or  ROC,  and  allows  the  ACAT  IIS  program  to  enter 
concept  exploration  after  budget  approval. 

The  POM  is  then  submitted  to  the  SECDEF  for  review  and  approval. 
If  the  SECDEF  endorses  a  new  start  represented  by  a  JMSNS,  inclusion  of 
the  new  start  in  the  DOD  budget  submitted  to  0MB  documents  that  endorse¬ 
ment  and  provides  the  program  initiation  decision.  This  endorsement 
allows  the  ACAT  I  program  to  enter  concept  exploration  when  the  budget 
is  approved. 

When  the  JMSNS  proposed  program  is  modified  by  SECDEF,  the  modifi¬ 
cations  are  documented  in  the  PDM,  the  SECDEF' s  reply  to  the  POM.  When 
a  Joint  or  OSD/JCS  JMSNS  is  submitted,  the  SECDEF  decision  is  documented 
in  an  SDDM. 


Interfacing  with  the  PPBS 

The  DOD  PPBS,  as  defined  in  DODI  7045.7,  is  the  framework  within 
which  SECDEF  and  SECNAV  decisions  are  made  to  determine  force  levels, 
weapons  systems,  and  support  programs.  Major  decisions  for  individual 
projects  are  made  in  the  context  of  both  the  acquisition  process  and  the 
PPBS.  The  PPBS  is  described  in  great  detail  in  The  Department  of  the 
Navy  Programming  Manual  prepared  by  0PNAV-90P.  A  short  course  covering 
the  system  is  given  by  OSD  at  the  Pentagon.  Further  information  on  this 
course,  which  is  recommended,  may  be  obtained  from  the  NMC  Acquisition/ 
Logistics  Management  Training  Center,  Naval  Station,  Anacostia,  Washing¬ 
ton  D.C.  20374. 

The  acquisition  process  proceeds  in  phases,  each  of  which  may 
require  only  a  part  of  a  budget  cycle  or  several  full  cycles.  Gearing 
tne  phases  to  the  particular  business  and  technical  aspects  of  tne 
program  ensures  that  adequate  in-depth  reviews  are  conducted  prior  to 
significant  commitment  of  resources.  By  contrast,  the  PPBS  runs  on  a 
tightly  structured  schedule  -  a  single  cycle  from  initial  planning 
through  congressional  enactment  to  actual  execution  requires  25  months. 
The  PPBS  decisions,  rather  than  being  oriented  to  the  needs  of  a  speci¬ 
fic  program,  are  keyed  to  the  larger  problem  of  balancing  all  of  the 
programs  within  the  DON,  DOD,  Office  of  Management  and  Budget  (0MB),  and 
congressional  financial  limits  established  for  a  particular  fiscal  year 
of  the  (FYDP) . 

Decisions  made  through  the  acquisition  process  need  to  be  reflected 
in  the  FYDP.  This  is  accomplished  either  during  the  POM/Issue  Paper/PDM 
process,  or  during  the  budgeting  process,  depending  on  when  the  mile¬ 
stone  decision  is  made.  The  PM  must  follow  these  processes  carefully 


because  his  program  funding  is  in  jeopardy  at  each  step  of  the  budgeting 
process.  Successfully  passing  a  milestone  decision  is  no  guarantee  of 
full  funding,  and  in  the  PQM/PDM/budget  process  the  program's  funding 
may  be  dropped  below  threshold. 


Defense  Resources  8oard  (ORB).  Top  level  DOD  review  of  the  POM/ 
budget  is  the  responsibility  of  the  Defense  Resources  Board  (DRB).  The 
membership  of  the  DRB,  based  on  a  Deputy  Secretary  of  Defense  Memorandum 
dated  27  March  1981,  includes: 

Chairman:  Deputy  Secretary  of  Defense 

Members:  Chairman  of  the  Joint  Chiefs  of  Staff 
Secretary  of  the  Army 
Secretary  of  the  Navy 
Secretary  of  the  Air  Force 
Under  Secretary  of  Defense,  Policy 
Under  Secretary  of  Defense,  Research  and  Engineering 
Assistant  Secretary  of  Defense,  Comptroller 
Assistant  Secretary  of  Defense,  Health  Affairs 
Assistant  Secretary  of  Defense,  International  Security 
Affairs 

Assistant  Secretary  of  Defense,  International  Security 
Policy 

Assistant  Secretary  of  Defense,  Manpower,  Reserve  Affairs 
and  Logistics 

Director,  Program  Analysis  and  Evaluation 
Associate  Director,  Office  of  Management  and  Budget 

The  makeup  of  the  DRB  is  very  similar  to  that  of  the  Defense 
Systems  Acquisition  Review  Council  (DSARC),  although  their  purposes  are 
different.  The  DRG  review  can  severely  impact  the  budgeting  of  major 
systems  acquisition,  as  occurred  with  the  F/A -18.  The  DSARC  deals  with 
a  single  system  at  a  time,  basing  decisions  on  the  technical  progress, 
acquisition  strategy,  implementation  plans,  and  accuracy  of  cost  projec¬ 
tions.  By  contrast,  the  DRB's  responsibility  is  to  advise  SECDEF  on  the 
overall  DOD  budget.  In  this  area,  each  program  must  compete  with  all 
other  programs  (including  those  of  other  Services)  for  dollars.  The  DRB 
recommends  to  SECDEF  a  priority  and  ranking  of  programs. 

In  the  event  a  POM  or  budget  submittal  to  OSD  deviates  significant¬ 
ly  from  a  previously  approved  milestone  decision,  this  fact  and  the 
cost,  schedule,  and  performance  impact  on  the  program  are  to  be  noted 
and  explained  in  tne  POM  or  budget  submittal.  In  such  instances,  the 
milestone  decision  is  a  decision  alternative  in  the  POM  or  budget. 

Figure  3-4  outlines  the  PPBS  sequence.  The  effect  of  this  interre¬ 
lationship  between  the  PPBS  arid  an  acquisition  program  is  that  adequate 
funding  for  the  critical  Concept  Exploration  Phase  is  unlikely  to  occur 
until  18  to  24  months  after  the  need  document  submittal  and  at  least  12 
months  after  its  approval  unless  reprogramming  is  carried  out.  A  step- 
by-step  descri,tion  of  the  PPBS  is  also  provided  in  Appendix  B, 

DOD  officials  are  investigating  the  possibility  of  establishing  OSD 
or  DOD  discretionary  funds  for  Concept  Exploration  Phase  funding.  For 
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FIGURE  3-4.  Sequence  of  PPBS  Events. 
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the  present,  however,  the  PM  most  establish  and  maintain  contact  with 
constituent  groups  and  individuals  in  the  DON  who  have  an  interest  in 
the  program  and  from  whom  he  might  obtain  the  necessary  support  for 
reprogramming  action. 

The  problem  of  obtaining  adequate  funding  during  the  Concept  Explo¬ 
ration  Phase  can  be  reduced  by  advanced  development  or  exploratory 
development  funds  into  ;he  mission  areas  that  will  directly  support  an 
anticipated  new  start. 

Since  the  PPBS  is  an  annual  event,  and  there  is  continuing  competi¬ 
tion  by  many  programs  for  the  same  funds,  the  PM  must  maintain  an 
awareness  of  the  status  of  the  budgeting  process  and  be  prepared  at  any 
time  to  support  his  OPNAV  sponsor  and  program  coordinator  in  defense  of 
his  project's  funding.  When  responding  to  questions  or  writing  appeals, 
the  PM  and  program  coordinator  must  work  as  a  unified  team.  CNM  labora¬ 
tory  and  contractor  support  may  also  be  helpful.  Sensitivity  to  the 
perspective  of  the  questioner  is  vital. 

The  PM  should  anticipate  budgeting  problems.  Alleviating  these  can 
be  one  of  the  most  urgent  problems  he  will  face.  He  must  know  the 
probable  opposition  and,  with  the  OPNAV  program  coordinator,  maintain  a 
forceful  dialogue  with  important  constituencies,  particularly  within  the 
Office  of  the  Comptroller  of  the  Navy  (NAVCOMPT). 


Significance  of  the  Program  Initiation  Decision 

Preparation  of  a  program  initiation  document  indicates  that  a 
specific  deficiency  or  opportunity  in  the  Navy's  mission  capability  has 
been  identified  and  approval  is  sought  to  take  appropriate  action.  When 
a  JMSNS  is  submitted  to  SECDEF,  the  DON  requests  that  the  program  be 
given  ACAT  I  designation.  Other  programs  may,  however,  be  submitted  for 
SECDEF  review  if  the  DON  feels  that  their  significance  so  warrants. 
Submission  of  such  a  JMSNS  to  SECDEF  constitutes  a  recommendation  by  the 
Navy  that  the  designation  of  an  acquisition  as  a  "major  system"  may  be 
based  on  the  critical  nature  of  the  deficiency,  the  amount  of  fiscal  and 
manpower  resources  required  for  a  major  system's  acquisition  and  opera¬ 
tion,  the  urgency  of  need,  development  risk,  joint  acquisition  consider¬ 
ation  (interservice,  NATO,  etc.),  or  congressional  interest. 

SECDEF,  by  approving  a  DON  budget  that  includes  the  JMSNS  program, 
signifies  his  agreement  with  the  statement  of  need  and  with  the  assess¬ 
ment  of  the  system  as  major.  His  approval  also  directs  the  Navy  to 
undertake  exploration  of  the  various  means  of  correcting  the  deficien¬ 
cy.  SECDEF  may  also  decide  that  a  program  represented  by  a  JMSNS  should 
be  designated  non-major.  In  such  a  case,  the  JMSNS  is  returned  to  the 
DON  for  action  and,  based  upon  criteria  in  SECNAVINST  5000.1,  assigned 
to  the  PDA  for  action.  The  program  initiation  decision  defines  a  start¬ 
ing  point  from  which  to  audit  cost  and  schedule  performance.  SECDEF 
approval  establishes  a  firm  DOD  position  relative  to  the  mission  need 
and  signifies  an  intent  to  satisfy  that  need.  For  ACAT  III  and  IV 
programs,  Milestone  I  will  normally  be  eliminated  and  approval  of  pro¬ 
gram  initiation  in  the  POM  authorizes  entry  into  the  Dc  nstration  and 
Validation  ( D&V )  Phase  unless  otherwise  directed.. 


CONCEPT  EXPLORATION  PHASE 


The  program  initiation  documentation  and  approval  of  the  budget 
marks  the  beginning  of  the  Concept  Exploration  Phase  during  which  al¬ 
ternative  concepts  are  solicited,  proposed,  and  selectively  evaluated. 
During  this  phase,  industry  and  in-house  R&D  laboratories/centers,  as 
well  as  universities  and  other  not-for-profit  institutions,  are  chal¬ 
lenged  to  conceptualize  and  submit  alternative  methods  for  meeting  the 
stated  mission  need.  In  addition,  in-house  studies  must  be  initiated 
for  independently  arriving  at  performance,  cost,  schedule,  and  suppcrta- 
bility  estimates  as  well  as  test  and  evaluation  (T&E)  criteria.  Figure 
3-5  is  an  overview  of  the  inputs,  principal  activities,  and  outputs  of 
the  Concept  Exploration  Phase. 


Concept  Exploration  Phase  Objectives 

The  objectives  of  the  Concept  Exploration  Phase  are  the  selection 
of  the  most  promising  system  concepts  for  the  Demonstration  and  Valida¬ 
tion  (D&V)  Phase  and  initial  preparation  of  plans  for  the  balance  of  the 
acquisition  process,  with  particular  emphasis  on  those  necessary  for  a 
favorable  Milestone  I  decision.  These  concepts  should  address  the 
functional  and  performance  characteristics  necessary  to  meet  the  mission 
element  need,  the  necessary  interfacing  capabilities,  and  should  be 
accompanied  by  preliminary  ’’fe-cycle  cost  (LCC)  estimates  and  logistic 
support  ability  plans.  While  primarily  paper-  or  study-oriented,  techni¬ 
cal  feasibility  models  or  critical  subsystems  may  be  developed  during 
this  phase.  These  are  used  for  examining  the  feasibility  and  practica¬ 
lity  of  the  technical  state-of-the-art  as  it  relates  toward  achieving 
the  specified  functional  program  requirements.  The  various  technical 
areas  are  examined  and  evaluated  without  regard  to  eventual  overall  fit 
or  form  cf  the  final  system.  The  outputs  of  this  phase  should  include 
contractor  or  laboratory  proposals  for  the  efforts  in  the  D&V  Phase  and 
the  required  milestone  review  documentation  (MRD),  i.e.  System  Concept 
Pape1"  (SCP)  and  Test  and  Evaluation  Master  Plan  (TEMP)  for  major  sys¬ 
tems;  or  the  Navy  Decision  Coordinating  Paper  (NDCP)  and/or  TEMP  for 
less-than-major  programs. 


Program  Start-Up 


The  start  of  the  Concept  Exploration  Phase,  or  other  formal  start¬ 
ing  point  for  the  program,  is  a  very  critical  time  in  the  life  of  the 
system.  Almost  immediately  after  being  appointed,  the  PM  is  expected  to 
participate  in  the  writing  of  his  "charter",  establishing  the  program 
office  and  supporting  team,  and  developing  the  acquisition  strategy 
which  will  be  the  framework  for  the  remainder  of  the  program.  The  PM's 
charter  and  factors  affecting  the  establishment  of  his  organization  and 
acquisition  team  ha/e  been  discussed  in  Section  2,  Program  Management. 
Preliminary  planning,  the  acquisition  strategy,  source  solicitation  and 
contracting  are  discussed  briefly  in  the  following  paragraphs  and  then 
in  more  detail  in  Section  4,  Critical  Topics. 
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FIGURE 


Inputs,  Activities,  Outputs  during  Concept  Exploration. 
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Preliminary  Planning.  One  of  the  hard-learned  lessons  of  Navy 
acquisition  is  that  planning  must  include  all  phases  and  related  activi¬ 
ties  from  inception  to  operation  support.  Problems  incurred  in  a  pro¬ 
gram  are  inversely  proportional  to  the  amount  of  planning.  That  does 
not  mean  the  PM  should  spend  all  of  his  time  in  planning  -  just  avoid 
the  desire  to  go  to  work  now  and  figure  out  where  he  is  going  later. 
Piecemeal  planning  results  in  poor  estimates  for  decision-making  pur¬ 
poses  and  reduces  the  reliability  and  credibility  of  planning  estimates. 
It  results  in  inadequate  allocation  of  resources  and  in  attempted  short¬ 
cuts  that  in  turn  lead  to  unnecessary  time  delays,  excessive  cost, 
inferior  performance,  and  inadequate  logistic  supportability.  More  than 
any  other  single  factor,  careful  planning  is  the  hallmark  of  a  success¬ 
ful  program.  Now  is  the  time  for  the  PM  to  step  back,  look  at  the 
overall  program,  and  prepare  his  preliminary  plan.  The  preliminary  plan 
is  a  foundation  for  the  more  detailed  planning  that  will  be  required  of 
the  PM  throughout  the  program. 

Among  the  factors  the  program  manager  (PM)  should  consider  in  his 
preliminary  planning  are: 

1 .  Need 

o  Program  criticality  or  urgency 

o  Scope  of  mission-area  requirements  to  be  met 

o  Background  of  the  need  document  (an  outgrowth  of  in-house 
technology  development,  the  result  of  an  unsolicited 
industrial  proposal,  etc.) 

2.  Acquisition  strategy  (required  of  Acquisition  Category  (ACAT) 

I - 1 1 1  programs  with  the  recommendation  that  ACAT  IV  programs 

follow  the  guidelines  for,  and  prepare  informal  strategy) 

o  Level  of  interest  in  program  to  determine  possible  im¬ 
pacts  on  acquisition  strategy  development/approval 

o  Previously  documented  decisions  which  may  impact  acquisi¬ 
tion  strategy 

o  Degree  of  newness  or  technical  risk  involved;  is  quick 

IOC  with  preplanned  product  improvement  desired? 

o  Impact  of  proposed  program  structure  (phases  and  mile¬ 

stones)  on  acquisition  strategy  development/approval 

o  How  to  obtain  as  much  competition  (and  no  more)  as  desir¬ 
able;  for  how  long?  Recent  DOD  and  Navy  policy  is  to 
agressively  exploit  all  opportunities  for  competitive 
procurement. 

3.  Organization 

o  Type  of  organization  needed  to  manage  the  program 
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o  Other  events  and  organizations  involved  in  the  acquisi¬ 
tion  process  (see  Figure  1-6,  Section  1) 

o  Proper  balance  of  logistics,  manning,  design  attributes 

4.  Preplanning  for  Full-Scale  Development  and  Production/Deploy¬ 
ment  Phases. 


Consult  with  Other  PMs.  In  conjunction  with  his  consideration  of 
these  factors,  the  f>M  should  consult  with  PMs  from  similar  sized  pro¬ 
grams.  No  two  programs  will  be  alike  but  there  will  be  similarities  and 
useful  insights  can  be  gained.  Particularly  valuable  are  the  comments 
of  PMs  of  programs  recently  introduced  into  service  use.  Their  lessons 
learned  can  help  a  new  PM  prevent  downstream  problems. 


Acquisition  Strategy.  Simultaneously  with  the  establishment  of  the 
PMO,  the  M  must  develop  and  refine  the  proposed  acquisition  strategy, 
which  must  be  submitted  within  90  days  after  program  initiation.  The 
acquisition  strategy  is  the  key  to  successful  program  planning  and 
serves  as  the  skeleton  structure  on  which  the  functional  implementation 
plans  for  the  remainder  of  the  program  will  be  hung. 

The  acquisition  strategy  is  one  of  the  vehicles  to  introduce  flexi¬ 
bility  into  the  acquisition  system  that  DOD  and  Navy  directives  encou¬ 
rage.  The  strategy  must  be  tailored  to  the  particular  program's  needs 
and,  in  its  preparation,  the  PM  should  consider  means  for  shortening  the 
acquisition  process;  introducing  and  maintaining  competition;  streamlin¬ 
ing  the  transition  from  development  to  production;  and  identifying  and 
resolving  development,  production  and  operational  risks.  The  acquisi¬ 
tion  strategy  and  its  development  in  the  Concept  Exploration  Phase  is 
discussed  in  greater  detail  in  Section  4,  Critical  Topics.  For  those 
programs  that  do  not  require  an  acquisition  strategy  paper  (ASP)  (new 
ACAT  IV  programs  and  revisions  to  existing  programs  started  before 
August  1981),  an  acquisition  plan  (AP)  will  be  used.  The  contents  of 
the  AP  are  similar  to  an  ASP  but  are  more  detailed  and  follow  the  format 
prescribed  in  FAR  7.00C. 


Support  Team.  The  activities  of  the  support  team  in  the  Concept 
Exploration  Phase  include  establishing  evaluation  methodologies,  defin¬ 
ing  interfaces  with  other  systems,  conducting  independent  cost  analyses 
of  the  competitive  concepts,  investigating  alternative  solutions  to 
program  problems,  assisting  in  the  collection  and  dissemination  of 
government -owned  information,  performing  technical  reviews,  and  assist¬ 
ing  the  source  selection  team  in  achieving  a  full  understanding  of  the 
proposed  concepts. 


Source  Solicitation  and  Proposal  Evaluation.  The  PM 
of  the  high-level  interest  in,  benefits  of  and  procedures 
tion  in  the  selection  of  concepts  for  development.  The  PM 
pro-active  role  regarding  the  extent  of  competition  on  his 


must  be  aware 
for  competi- 
must  assume  a 
program. 
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The  solicitation  must  describe  the  mission  need  in  terms  of  the 
minimum  acceptable  performance  goals,  the  anticipated  operational  envi¬ 
ronment,  MIL-SPECs  of  required  interfaces,  and  the  criteria  by  which  the 
proposals  will  be  evaluated.  Additional  discussion  on  solicitation  is 
provided  in  Section  4,  Critical  Topics. 

The  PM  must  encourage  and  give  equal  consideration  to  the  inputs  of 
industry.  Naval  laboratories/centers,  federal  contract  research  centers, 
not-for-profit  organizations  and,  if  appropriate,  foreign  sources. 

The  evaluation  criteria  should  be  included  in  the  solicitation  as 
well  as  the  data  and  data  format  required  for  evaluation.  Evaluation 
criteria  should  be  flexible  enough  to  be  applied  to  the  most  diverse 
alternative  concepts  and  yet  they  must  be  sufficiently  structured  to 
permit  equitable  application  to  all  proposals. 

Proposals  in  response  to  the  request  for  proposal  { RFP )  should  be 
evaluated  in  accordance  with  the  approved  source  solicitation  plan.  The 
responses  to  the  solicitation  should  identify  items,  designs  or  compo¬ 
nents  that  the  contractors  consider  proprietary  or  sole  source,  and  the 
cost  and  terms  required  for  the  government  to  use  or  to  acquire  them. 


Contracting.  After  the  most  promising  concepts  have  been  selected 
from  the  solicitation  responses,  parallel  short-term  contracts  for  fur¬ 
ther  study  are  awarded.  The  PM  should  avoid  the  urge  to  reduce  his 
front-end  expen-diture  of  time  and  money  since  this  may  lead  to  a  com¬ 
bination  of  higher  costs  and  lower  performance  levels  in  later  stages. 
The  contracts  issued  during  the  Concept  Exploration  Phase  should  provide 
for  easy  augmentation  to  permit  the  further  exploration  of  promising 
concepts  in  greater  and  greater  depth  while  eliminating  less  appealing 
concepts. 


Contract  Monitoring 

Close  monitoring  of  the  ongoing  contracts  by  competent  technical 
and  managerial  personnel  is  essential.  The  PM  may  employ  Navy  laborator¬ 
ies/centers  and/or  other  Navy  field  activities  during  this  period  to 
identify  potential  technical  problems  and  work  towards  their  solution. 


Technical  Transfusion 


The  contractors  must  be  treated  equally.  A  technical  library 
containing  government-owned  information  relative  to  the  program,  includ¬ 
ing  scenarios,  mission  analyses,  threat  information,  and  the  results  of 
government- sponsored  research  and  development,  is  usually  established 
at  the  lead  laboratory  and  made  accessible  to  all  participants. 

The  accidental  or  other  technical  transfusion  from  one  concept  to 
another,  or  transfer  of  information  on  the  status,  conclusions  and/or 
findings  of  one  competitor  to  another,  must  be  tightly  controlled. 
Testimony  by  the  USDR&E  to  Congress  indicates  that  technical  transfusion 
may  take  place  when  it  is  in  the  best  interest  of  the  U.S.  Government. 
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Such  technical  transfusion  can  occur  if  the  government  purchases  the 
technical  proposals  from  industry  including  full  data  rights.  In  such  a 
case,  the  best  parts  of  several  proposals  may  even  be  combined  into  one 
overall  concept.  Care  must  be  exercised  in  doing  this,  and  then  only 
with  the  full  concurrence  of  the  bidders.  Full  information  concerning 
what  transfusions  will  be  permitted  and  how  they  will  be  permitted  to 
take  place  must  be  provided  to  the  prospective  contractors  prior  to 
negotiating  the  original  Concept  Exploration  Phase  contracts.  It  has 
been  the  general  concensus  of  industry  that  there  is  no  need  for  techni¬ 
cal  transfusion. 


Proposal  for  the  Demonstration  and  Validation  (D&V)  Phase 

In  order  to  maintain  program  continuity,  each  contractor  should  be 
required  to  submit  a  comprehensive  technical  and  cost  proposal  for 
accomplishing  the  D&V  Phase  effort. 


Negotiations  for  D&V  Phase  Contracts 

Negotiations  for  follow-on  work  should  be  conducted  while  the 
maximum  competition  exists  prior  to  selection  of  the  most  promising 
candidates  for  the  D&V  Phase.  Final  selection  should  be  made  at  the 
conclusion  of  the  Concept  Exploration  Phase  using  the  previously  devel¬ 
oped  criteria.  Funds  should  be  programmed  to  allow  work  to  proceed  on 
the  alternative  concepts  selected  for  continuation  into  the  D&V  Phase 
while  the  formal  milestone  review  documentation  is  being  prepared  and 
the  Milestone  I  review  is  conducted. 

Status  Reporting 

NMC  Selected  Acquisition  Tracking  System  ( NSATS ) .  NSATS  provides 
information  on  the  qualitative  status  of  selected  Navy  acquisition 
programs  and  assists  in  the  early  identification  and  solution  of  program 
problems.  All  ACAT  I  and  II  acquisition  programs  are  required  by  NAV¬ 
MAT  INST  5200. 43B  to  report  via  the  Acquisition  Program  Status  Report, 
NAVMAT  Form  5200/5  (Rev.  11/82),  on  a  quarterly  basis.  The  PM  is  re¬ 
sponsible  for  preparing  the  NSATS  report.  Upon  approval  by  the  SYSCOM 
Commander,  the  report  is  forwarded  to  the  CNM.  Analysis  and  dissemina¬ 
tion  of  this  information  is  performed  by  the  NAVMAT  Acquisition  Divi¬ 
sions. 


MILESTONE  I 

Milestone  I  Review  Documentation  (MRP) 

The  MRD  for  Milestone  I  depends  upon  the  acquisition  category  of 
the  program.  The  Navy  uses  the  following  documentation: 

System  Concept  Paper  (SCP).  The  SCP  is  used  for  ACAT  I  programs  to 
summarize  the  results  of  the  Concept  Exploration  Phase  and  to  describe 
the  Navy's  acquisition  strategy.  The  SCP  will  include  identification  of 


3-18 


concepts  to  be  carried  into  the  D&V  Phase  and  reasons  for  elimination  of 
other  concepts;  the  extent  of  competition  planned  for  each  subsequent 
phase;  the  need  for  industrial  base  capacity  enhancement  and/or  manufac¬ 
turing  technology  development,  as  well  as  critical  or  unusually  long- 
lead  materials;  the  program  structure;  and  a  discussion  of  how  the 
acquisition  process  will  be  tailored  to  fit  the  program  (including 
service  and  SECDEF  milestone  decision  points).  The  SCP  will  also  estab¬ 
lish  goals  and  thresholds  to  be  attained  at  Milestone  II,  and  will  treat 
any  other  relevant  issues  that  may  have  been  exposed  during  concept 
development.  The  SCP  is  not  to  exceed  12  pages  (excluding  five  annex¬ 
es).  See  DODI  5000.2.  for  required  SCP  format. 

Navy  Decision  Coordinating  Paper  (NDCP).  The  NDCP  is  required  for 
all  AtAT  i I  programs.  the  NDCP  provides  the  basic  review  documentation 
for  use  in  determining  the  previous  phases  progress  and  making  recommen¬ 
dations  to  the  SECNAV  and/or  CNO/CMC  for  the  Milestone  I,  II,  or  III 
decisions.  It  is  limited  to  three  pages,  excluding  4  annexes.  The  NDCP 
content  should  supplement  and  not  reproduce  information  contained  in  the 
TEMP.  The  NDCP  should  be  issue  oriented;  emphasizing  the  acquisition 
strategy,  competition  and  contracting,  production  planning,  anticipated 
risk  areas  and  means  of  overcoming  them,  acquisition  logistics,  and 
manpower.  See  SECNAV INST  5000.1  for  required  NDCP  format. 

Test  and  Evaluation  Master  Plan  (TEMP).  The  TEMP  required  for  ACAT 
I  programs  is  defined,  in  DODD  5000.3,  as  a  summary  document  of  not  more 
than  30  pages.  The  TEMP  is  also  required  by  0PNAVINST  3960.10  for  all 
ACAT  II,  III  and  IV  programs  and  is  limited  to  twelve  pages.  It  is  to  be 
a  short,  concise  master  plan  for  T&E.  For  ACAT  III  and  IV  programs,  the 
TEMP  is  the  single  document  by  which  the  program  is  controlled.  Its 
purposes  are  to  identify  all  required  T&E  resources;  facilitate  long- 
range  planning,  programming,  and  budgeting  including  that  of  adequate 
numbers  of  test  hardware  items  and  specialized  major  range  and  test 
facility  base  (MRTFB)  facilities;  ensure  accomplishment  of  adequate  T&E; 
eliminate  redundant  testing;  and  reduce  Fleet  RDT&E  support  requirements 
to  the  minimum.  The  TEMP  forms  the  basic  "contract"  between  the  devel¬ 
opment  activity  (DA)  and  C0M0PTEVF0R,  or  the  President  of  the  Board  of 
Inspection  and  Survey  (PRESINSURV) ,  or  Marine  Corps  Operational  Test  and 
Evaluation  Agency  (MCQTEA),  when  appropriate,  for  conduct  of  the  overall 
T&E  effort.  While  the  initial  version  of  the  TEMP,  required  at  Mile¬ 
stone  I,  will  lack  many  specifics,  the  interative  revision  process  will 
develop  the  necessary  detail.  This  is  further  discussed  in  Section  4, 
Critical  Topics. 

Secretary  of  Defense  Decision  Memorandum  (SDDM).  The  SDDM  docu¬ 
ments  each  SECDEE  decision  (Joint  Service  JMSNSs,  all  ACAT  I  program 
Milestones  I  and  II;  and,  if  required.  III).  The  SDDM  establishes 
program  goals  and  thresholds,  reaffirms  established  needs  and  program 
objectives,  authorizes  exceptions  to  acquisition  policy  (when  appropri¬ 
ate),  and  provides  OSD,  JCS,  and  the  DON  with  direction  and  guidance  for 
the  next  phase  of  acquisition. 

Secretary  of  the  Navy  Decision  Memorandum  (SNDM).  The  SNDM  is  used 
to  provide  tKe  StCNAV's  decisions  for  ACAT  IlS  programs  and  include 
approval  of  exceptions  to  the  normal  acquisition  process  and  other 
directions.  Normally,  the  SNDM  is  issued  within  15  working  days  follow- 
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ing  a  milestone  decision  review.  A  new  SNDM  is  issued  to  revise  goals/ 
thresholds  or  other  program  direction  when  required  by  threshold  breach 
or  PPBS  or  Congressional  action.  The  SNDM  serves  the  same  purpose  for 
ACAT  IIS  programs  as  the  SDDM  serves  for  ACAT  I  programs. 

Decision  Authority  Decision  Memorandum  (DADM) .  The  DADM  is  used  to 
provide  the”  ACAT  lit  and  IV  PDA'S  direction  after  a  milestone  review  and 
serves  the  same  purpose  as  the  SDDM  and  SNDM. 

Sponsor  Program  Review  (SPR)  Decision  Document  (SPRDD).  The  SPRDD, 
similar  in  nature  to  the  SDDM  and  SNDM,  is  used  to  provide  the  OPNAV 
sponsor's  decisions  for  ACAT  III  program  milestone  decisions. 


Special  Milestone  Review  Officials  and  Groups 

There  are  a  number  of  special  milestone  review  groups  and  individ¬ 
uals  who  are  involved  in  reviewing  and  making  recommendations  during  the 
Milestone  I,  II,  and  III  decision  process.  They  are  as  follows: 

Defense  Acquisition  Executive  (DAE).  The  DAE,  in  accordance  with 
DODD  5000 .T,  is  the  principal  advisor  and  staff  assistant  to  the  SECDEF 
for  the  acquisition  of  defense  systems  and  equipment.  The  DAE  serves  as 
a  permanent  member  and  chairman  of  the  DSARC.  In  coordination  with  other 
DSARC  members,  he:  integrates  and  unifies  the  management  process,  poli¬ 
cies  and  procedures  for  defense  system  acquisition;  monitors  DON  com¬ 
pliance  with  the  policies  and  practices  in  the  0MB  Circular  A-109,  DODD 

5000.1,  D0DI  5000.2  and  DODD  5000.3;  ensures  that  the  requirements  and 
viewpoints  of  functional  areas  are  given  full  consideration  during  staff 
and  DSARC  deliberations,  and  are  integrated  into  the  recommendations 
sent  to  the  SECDEF;  and  ensure  consistency  in  applying  the  policies 
regarding  NATO  RSI  for  all  major  systems.  The  USD ( R&E )  has  been  desig¬ 
nated  as  the  DAE. 

Defense  Systems  Acquisition  Review  Council  (DSARC).  The  functions 
and  membership  oT  tKe  DSARC  are  described  in  DODD  5000.1  and  DODI 

5000.2.  Basically,  the  DSARC  provides  advisory  support  to  the  SECDEF  on 
acquisition  matters.  DSARC  membership  includes 

Chairman  Defense  Acquisition  Executive 

Members  Under  Secretary  of  Defense,  Research  and  Engineering 
Under  Secretary  of  Defense,  Policy 

Assistant  Secretary  of  Defense,  Manpower,  Reserve  Affairs 
and  Logistics 

Assistant  Secretary  of  Defense,  Comptroller 
Director,  Program  Analysis  and  Evaluation 
Chairman,  Joint  Chiefs  of  Staff  or  his  representative 
Service  Secretary  or  his  representative 

Navy  Acquisition  Executive  (NAE).  According  to  SECNAVINST  5000.1, 
the  NAE  is  ^designated  by  the  SElNAV  and  has  lead  authority  and  responsi¬ 
bility  for  a  specific  acquisition  program. 

The  Assistant  Secretary  of  the  Navy,  Research,  Engineering  and 
Systems  [ASN(RE&S)]  is  the  NAE  for  all  R&D  programs  and,  with  the  excep- 
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tion  of  ship  design  and  construction,  is  responsible  for  the  management 
of  R&D  programs  up  to  the  point  where  a  decision  is  made  to  transition 
to  full-scale  production. 

The  Assistant  Secretary  of  the  Navy,  Shipbuilding  and  Logistics 
[ASN(S&L)]  is  the  NAE  for  all  aspects  of  ship  design  for  ships  in  the 
Five-Year  Shipbuilding  Program  and  for  management  and  support  of  all 
programs  after  the  Milestone  III  decision  is  made  to  transition  to  full- 
scale  production. 

The  Assistant  Secretary  of  the  Navy,  Manpower  and  Reserve  Affairs 
[ASN(M&RA)3  is  the  NAE  for  all  aspects  of  manpower  and  training  as 
affecting  the  design  and  development  of  DON  systems. 

Competition  Advocate  General .  The  Competition  Advocate  General 
reports  both  to  the  CNM  and  the  ASN(SSL)  and  is  responsible  for  aggres¬ 
sively  fostering  competition  in  the  Navy  by:  reviewing  and  approving 
acquisition  strategy  planning  in  all  Navy  acquisition  programs;  foster¬ 
ing,  developing,  maintaining,  overseeing  and  directing  the  Navy  Competi¬ 
tion  Plan;  developing,  maintaining  and  overseeing  policy  and  procedures 
to  implement  competition  in  the  Navy;  providing  direct  staff  assistance 
to  the  SECNAV  and  ASN  in  the  area  of  competition  advocacy  in  his  role  as 
Competitive  Acquisition  Executive;  and  fostering  and  maintaining  aggres¬ 
sive  interaction  dialogue  with  industry  and  competitive  advocates  in 
other  services  as  well  as  those  at  all  levels  in  the  Navy. 

Department  of  the  Navy  Systems  Acquisition  Review  Council  (DNSARC) . 
The  DNSARC,  as  defined  in  SECNAVlNSY  5066. 1 ,  functions  as  the  review 
body  for  AC AT  IIS  programs  and  ACAT  I  programs  prior  to  SECDEF/  DSARC 
review.  The  DNSARC  membership  includes 

Chairman:  Navy  Acquisition  Executive 

Members:  Assistant  Secretaries  of  the  Navy 

Deputy  Under  Secretary  of  the  Navy,  Financial  Management 
General  Counsel 

Director,  Office  of  Program  Appraisal 
Chief  of  Naval  Operations 
Commandant  of  the  Marine  Corps 
Chief  of  Naval  Material 

In  addition,  the  Technical  Director  of  the  cognizant  CNM  R&D  Center 
will  be  called  upon  to  give  an  independent  critique  of  technological 
risks  associated  with  the  recommended  alternative  concepts. 

Chief  of  Naval  Operations  Executive  Board  (CEB).  The  CEB's  mis¬ 
sion,  as  stated  in  OPNAVINST  5420.2,  is  to  advise  the  CNO.  The  CEB 
convenes  to  consider  decision  alternatives  on  all  major  acquisition 
programs  prior  to  review  by  the  SECNAV  and  SECDEF.  The  membership  of  the 
CEB  is  as  follows: 

Chief  of  Naval  Operations 

Vice  Chief  of  Naval  Operations 

Chief  of  Naval  Material 

Director,  Navy  Program  Planning 

Commandant  of  the  Marine  Corps  (Associate  Member) 


Acquisition  Review  Committee  (ARC).  The  ARC  of  the  CNO  Executive 
Board  '(c^Bf,  according  to  OPNAVlNsT  5420.2,  is  to  function  as  a  review 
board  for  all  programs  except  for  ship  acquisition  and  conversion.  Its 
membership  consists  of: 

Chairman:  Director,  Navy  Program  Planning 

Members:  Director,  Naval  Warfare 

Director,  Research,  Development,  Test,  and  Evaluation 
Deputy  Chief  of  Naval  Operations  (Manpower,  Personnel, 
and  Training) 

Deputy  Chief  of  Naval  Operations  (Logistics) 

Ship  Characteristics  and  Improvement  Board  (SC IB).  The  tasks  of  the 
SC1B  of  the  CEfe,  in  accordance  with  0PNAVIN5T  5420.2,  include  the  cen¬ 
tralized  formulation  and  coordination  of  the  Navy's  shipbuilding  and 
conversion  programs,  the  Fleet  Modernization  Program  (FMP)  and  ship's 
characteristics  determination  for  the  active  and  reserve  fleets.  SCIB 
membership  includes: 

Chairman  Deputy  Chief  of  Naval  Operations  (Surface  Warfare) 

Members  Director,  Navy  Program  Planning 
Director,  Naval  Warfare 

Deputy  Chief  of  Naval  Operations  (Submarine  Warfare) 
Deputy  Chief  of  Naval  Operations  (Logistics) 

Deputy  Chief  of  Naval  Operations  (Air  Warfare) 

Commander,  Naval  Sea  Systems  Command 

Air  Characteristics  Improvement  Boaru  (ACIB).  The  ACIB  has  respon¬ 
sibility  for  all  matters  pirtaining  to  aircraft  and  aircraft  systems  and 
weapons  including:  engineering  change  proposals  (ECPs),  future  require¬ 
ments;  modification;  and  aircraft  and  aircraft  systems  and  weapons  the 
PMP  process,  (NOTE:  This  description  will  be  expanded  when  the  OPNAV¬ 
INST  covering  the  ACIB  is  complete  and  approved.) 

Sponsor's  Program  Review  (SPR).  The  SPR,  as  established  by  OPNAV¬ 
INST  5666.42,  is  the  forum  for  making  milestone  decisions  for  ACAT  III 
programs.  Decision  advisors  to  the  QPNAV  sponsor  include  representatives 
from  the  following: 

Office  of  Program  Planning 

Office  of  Naval  Warfare 

Office  of  Research,  Development,  Test  and  Evaluation 

Deputy  Chief  of  Naval  Operations  (Logistics) 

Conmander,  Operational  Test  and  Evaluation  Force 

Chief  of  Naval  Material 

Acquisition  Review  Board  (ARB).  The  CNM,  by  NAVMATINST  5000.19, 
and  in  keeping  with  0$6  policy,  Bisestablished  the  NAVMAT  ARB  and  has 
delegated  this  responsibility  to  the  SYSCOMs.  The  SYSC0M  ARBs  serve  as 
the  principal  forum  for  acquisition  review  of  ACAT  I,  II  and  III  pro¬ 
grams.  The  purpose  of  the  ARB  is  to  ensure  that  the  milestone-review 
presentation  accurately  reflects  the  CNM  position,  that  the  program 
itself  is  logical  and  executable  from  a  budgetary,  business  and  techno¬ 
logical  standpoint  and  complies  with  applicable  tasking  from  higher 
authority.  The  ARB  also  serves  as  the  forum  in  which  the  SYSC0M  Comman- 
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der  exercises  program  decision  authority  for  those  ACAT  IV  programs 
delegated  to  him. 

Logistics  Review  Board  (LRG).  All  ACAT  I  and  II  programs  (with  the 
exception  of  systems  under  the  responsibility  of  the  Director,  Strategic 
Systems  Project  Office  (SSPC)  and  the  Nuclear  Power  Directorate,  Naval 
Sea  Systems  Command)  and  selected  ACAT  III  and  IV  programs  will  be 
reviewed  at  key  milestones  by  a  CNM-corstituted  LRG  to  verify  the  ade¬ 
quacy  of  ILS  management  and  implementation. 

In  addition  to  the  LRG  membership  listed  below,  representatives 
from  CMC,  ASNtS&L) ,  CNET,  CNO(L),  DCN0(M,P&T)  and  DCNO  program  sponsors 
are  invited,  as  full  members,  and  encouraged  to  participate  in  the 
logistic  review. 

Chairman  Deputy  Chief  of  Naval  Material  (Logistics) 

Members  Vice  Commander,  Naval  Supply  Systems  Command 

Participants  in  review  of  cognisant  SYSCOM  projects: 

Deputy  Commander,  Naval  Sea  Systems  Command  Acquisition  and 
Logistics 

Assistant  Commander,  Naval  Air  Systems  Command,  Logistics/ 
Fleet  Support 

Deputy  Commander,  Naval  Elecvronics  Systems  Command,  Life 
Cycle  Engineering  and  Platform  Integration 

Vice  Commander,  Naval  Facilities  Engineering  Command 

Associated  Members,  participate  in  all  reviews: 

Deputy  Commander,  Naval  Supply  Systems  Command,  Fleet  Support, 
Corporate  Plans  and  Logistics 

Deputy  Chief  of  Naval  Material  for  Reliability,  Maintainabili¬ 
ty  and  Quality  Assurance 

Deputy  Chief  ov  Naval  Material,  Acquisition 

Directors  of  Deputy  Chief  of  Naval  Material,  Logistics  Divi¬ 
sions 


Preparation  for  Milestone  I  Review 

Considerable  work  and  time  are  required  for  the  Milestone  I  forma) 
review.  As  a  minimum,  the  PM  can  look  forward  to  at  least  17  hurdles, 
as  shown  in  Figure  3-6,  before  an  ACAT  I  program  is  reviewed  and  approv¬ 
ed  by  the  SECDEF.  This  preparation  will  include  updating  of  the  acqui¬ 
sition  strategy  with  emphasis  on  the  next  phase.  (A  list  of  essential 
considerations  is  given  in  Section  4  under  "Acquisition  Strategy,". 

When  it  is  considered  desirable  by  either  the  Defense  Acquisition 
Executive  (DAE)  or  the  PM,  an  informal  milestone  planning  meeting  (MPM), 
to  identify  program  issues,  may  be  held  before  DON  submission  of  the 
MRD.  The  meeting  can  be  requested  once  the  PM  is  sure  the  program  will 
achieve  its  phase  objectives  prior  to  the  proposed  DSARC  meeting.  The 
MPM  is  held  about  6  months  prior  to  the  scheduled  DSARC  meeting  and 
marks  the  start  of  the  formal  milestone  review  process.  The  DOD  calen- 
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FIGURE  3-6.  ACAT  I  Formal  Program  Reviews. 


dar  of  events  leading  to  the  DSARC  is  given  in  DODI  5000.2.  Figure  3-7 
is  a  sample  schedule  of  DSARC  planning  activities  for  ACAT  I  programs. 


Milestone  I  Review  and  Approval 

The  detailed  step-by-step  description  of  the  Milestone  I  review  and 
approval  process,  i.e.,  concept  selection  and  approval  to  enter  the  D&V 
Phase  -  is  provided  in  in  Appendix  A.  The  three  main  steps  are: 

(1)  the  PM  prepares  the  MRD  -  SCP/NDCP/TEMP  -  and  submits  it  fo. 
review,  via  the  chain  of  command,  to  the  PDA  (SCP/NDCP)  and 
OP-098  (TEMP); 

(2)  following  review  of  the  MRD,  completion  of  an  ILS  audit  and 
ILS  certification,  the  PM  prepares  and  presents,  via  the  chain 
of  command,  a  briefing  which  concentrates  on  the  issues  iden¬ 
tified  during  the  documentation  review  process;  and 

(3)  the  PDA  makes  his  decision  and  provides  his  direction  -  SDDM/ 
SNDM/DADM/SPRDD. 

NOTE:  The  Milestone  I  review  and  approval  process  applies 

primarily  to  ACAT  I  and  II  programs.  ACAT  III  and  IV  programs 
normally  do  not  have  a  Milestone  I  review  since  approval  of 
their  program  initiation  authorizes  entry  into  the  D&V  Phase. 


For  ACAT  IV  programs,  if  a  Milestone  I  review  is  required,  the  PM 
makes  his  presentation  to  the  SYSCOM  ARB  and  approval  to  proceed  into 
the  D&V  Phase  is  provided  by  the  SYSCOM  Commander  in  a  DADM. 

For  ACAT  III  programs,  if  a  Milestone  I  review  is  required,  the 
PM's  briefing  is  presented  to  the  SYSCOM  ARB  and  the  SPR  for  review  and 
recommendations.  The  OPNAV  sponsor's  approval  to  proceed  into  the  D&V 
Phase  is  provided  in  a  SPRDD. 

For  ACAT  1 1 C  programs,  the  PM's  briefing  is  presented  to  the  ARB, 
ARC  and  the  ACIB  or  SCIB  as  appropriate.  Some  experienced  PMs  believe 
that  the  pre-ARC  meeting  is  the  biggest  hurdle  of  the  review  cycle  and 
that  the  PM  should  really  concentrate  on  this  one.  After  this  hurdle, 
the  rest  are  relatively  easy.  The  ARC/ACIB/SCIB  provide  their  recommen¬ 
dations  to  the  CNO.  In  turn,  the  CNO  provides  his  approval  to  proceed 
to  the  D&V  Phase  in  a  DADM. 

For  ACAT  IIS  programs,  the  PM's  briefing  is  presented  to  the  ARB, 
CEB  and  DNSARC.  The  DNSARC  s  reenmev  ndations  are  provided  to  SECNAV. 
If  the  SECNAV  is  in  agreement  that  an  ACAT  IIS  should  proceed  into  the 
D&V  Phase,  his  approval  is  provided  in  a  SNDM. 

For  ACAT  I  programs.,  after  basically  following  the  ACAT  IIS  proced¬ 
ure,  the  PM's  briefing  is  then  presented  V  the  DSARC.  The  DSARC  makes 
its  recommendations  to  SECDEF  who,  if  in  agreement  that  the  progra- 
should  enter  the  D&V  Phase,  documents  his  approval  in  a  SDDM. 
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FIGURE  3-7.  Milestone  Planning  Schedule  for  ACAT  I  Programs. 
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NOTE:  Usually  DSARCs,  DNSARCs,  CEBs,  ARCs,  ACIBs  and  SCIBs 

have  "pre-briefs". 


All  TEMPs  are  cosigned  by  the  Development  Activity  (DA)  and  COMOP- 
TEVFOR.  Approval  authority  rests  with  the  DA  for  al1  ACAT  IV  TEMPs. 
with  OP-098  for  ACAT  II  and  III  TEMPs  and  the  SECDEF  for  all  ACAT  I 
TEMPs.  The  DDT&E  must  approve  Part  IV  of  ell  TEMPs  for  programs  which 
require  the  preparation  of  Selected  Acquisition  reports  { SARs ) .  Appro¬ 
val  of  the  the  TEMP  by  the  approval  authority  constitutes  direction  to 
conduct  the  T&E  program  contained  therein  and  includes  the  commitment  of 
Fleet  RDT&E  support.  While  the  initial  version  of  the  TEMP  required  at 
Milestone  I  will  lack  many  specifics,  the  iterative  revision  process 
will  develop  the  necessary  detail.  The  TEMP  will  be  reviewed  annually 
and  about  two  months  prior  to  major  decision  milestones  and  will  be 
updated  as  required  to  incorporate  significant  results  achieved  and 
changes  to  plans  and  milestones.  The  reasons  for  changes  will  be  docu¬ 
mented. 


Significance  of  Milestone  I 


Milestone  I  is  the  second  critical  review  point,  in  the  acquisition 
process.  A  favorable  decision  by  the  PDA  indicates  his  reaffirmation  cf 
the  program  mission  need  and  objectives,  and  approval  of  the  PM's  selec¬ 
tion  of  system  design  concepts  to  continue  into  the  D&V  Phase  or  autho¬ 
rization  to  proceed  with  the  development  of  a  noncompetitive  (single 
concept)  system.  This  decision  is  documented  in  the  decision  memoran¬ 
dum,  which  (1)  approves  program  goals,  thresholds,  and  proposed  use  of 
P3I  plan;  (2)  authorizes  exceptions  tc  normal  acquisition  policy  (when 
appropriate);  and  (3)  gives  direction  and  guidance  for  the  D&V  Phase. 


DEMONSTRATION  AND  VALIDATION  (D&V)  PHASE 

Milestone  I  marks  the  beginning  of  the  D&V  Phase.  In  this  phase, 
analyses,  hardware  fabrication,  and  T&E  will  verify  that  tho  risks  and 
uncertainties  for  at  least  one  of  the  developed  concepts  are  identify  ■ 
and  reduced  to  acceptable  levels.  The  phase  will  establish  that  the 
needed  technology  is  at  hand  so  that  only  engineering  development  (ra¬ 
ther  than  exploratory  development!  is  required  to  bring  the  concept (s) 
to  fruition.  Mission  and  performance  envelopes  for  the  system  will  be 
defined,  and  thorough  trace-off  analyses  of  threshold  capabilities 
versus  cost  will  be  made  so  that  selection  of  a  concept  for  Full-Scale 
Development  (FSD)  can  be  made.  During  the  D&V  Phase  the  allocated 
baseline  configuration  and  other  documentation  necessary  to  initiate  the 
FSD  Phase  are  prepared.  Figure  3-8  is  an  overview  of  the  inputs,  prin¬ 
cipal  activities,  and  outputs  of  this  phase.  Figure  3-9  summari/.es  the 
duties  that  must  be  performed  in  order  to  meet  the  objective  of  the  D&V 
Phase. 

The  D&V  Phase  is  pivotal  in  the  acquisition  process.  Dollar  expen¬ 
ditures  during  this  phase  represent  only  about  3%  of  the  system  ICC. 
However,  since  expenditures  in  the  succeedin'.-)  phases  are  largely  deter- 
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SIMULATOR,  TRAINING  AIDS 
DEVELOPMENT  PLANS 

•  MILESTONE  D  MRD 

•  MILESTONES  DECISION 

MEMORANDUM 


OT 

-  development  test 

MP&TS 

-MANNING.  PERSONNEL  ANO  TRAINING 

DTC 

-  design-to-cost 

MRD 

-MILESTONE  REVIEW  DOCUMENTATION 

ILS 

-  INTEGRATED  LOGISTIC  SUPPORT 

QT 

-  OPERATIONAL  TEST 

LCC 

-  LIFE-CYCLE  COST 

RFP 

-REDDEST  FOR  PROPOSAL 

LRG 

WNQ 

-  LOGISTIC  REVIEW  GROUP 
-MISSION  NEED  DETERMINATION 

TEMP 

-TEST  AND  EVALUATION  MASTER  PLAN 

FIGURE  3-8. 


Inputs,  Activities, 


Outputs  during  D&V. 
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•  UPDATE  ACQUISITION  STRATEGY 

•  FORMULATE  FUNCTIONAL  IMPLEMENTATION  PLANS 

•  ADOPT  EFFECTIVE  TECHNIQUES  FOR  OFFSETTING  THE  IMPACT  OF  UNCERTAINTIES 

•  CONSIDER  USING  THE  EVOLUTIONARY  INTRODUCTION  OF  NEW  TECHNOLOGY  THROUGH  PRE¬ 
PLANNED  PRODUCT  IMPROVEMENT  (p3|j  RATHER  THAN  DELAYING  tOC  AWAITING  NEW 
TECHNOLOGY 

•  BUDGETING  FUNDS  FOR  TECHNOLOGICAL  RISK  (E.G.  TRACE*) 

•  COST  AND  BUDGET  MORE  accurately 

•  INDEPENDENTLY  DEFINE  SYSTEM  AFFORDABILITY  PARAMETERS 

•  LIFE  CYCLE  COST/OESIGN-TO-COST 

•  REQUIRE  CONTRACTORS  TO  ESTIMATE  MORE  ACCURATELY  BY  UTILIZING; 

•  COST  REALISM  AS  A  SOURCE  SELECTION  CRITERION 

•  INCENTIVES  FOR  MEETING  COST  GOALS 

•  INCENTIVES  TO  MAKE  OESIGN-TO-COST  (DTC)  A  VIABLE  TOOL 

•  PROVIOE  ADEQUATE  FUNDS  FOR  TEST  HARDWARE  TO  ENSURE  COMPLETE  TEST  DATA  AND  TO 
PROVIDE  TEST  ARTICLES  DEVOTED  TO  RELIABILITY  AND  SUPPORTABILITY  TESTING 

•  BUDGET  MORE  REALISTICALLY  FOR  INFLATION. 

•  USE  BUSINESS  BASE  PROJECTIONS  IN  DECISION-MAKING 

•  CONTRACT  FOR  COMPETITIVE  DEMONSTRATIONS  OF  CONCEPTS.  EACH  DEVELOPER  MUST; 

•  DEMONSTRATE  CRITICAL  TECHNOLOGY/COMPONENTS/SUBSYSTEMS 

•  IDENTIFY  TECHNOLOGY  AND  PRODUCTION  RISK  AREAS.  OUTLINE  PROPOSED  PROGRAM  FOR 
OVERCOMING  RISKS 

«  DEFINE  CONCEPT  SPECIFIC; 

•  MAINTAINABILITY/RELIABILITY  PLAN 

•  LOGISTICS  REQUIREMENTS 

•  SYSTEM  SAFETY  REQUIREMENTS 

•  LIFE  CYCLE  COSTS 

•  PROPOSED  TEST  REQUIREMENTS 

•  MANNING  LEVELS/SKILLS/TRAINING  REQUIREMENTS/SIMULATOR  DEVELOPMENT 

•  SURVIVABILITY/VULNERABILITY  REDUCTION  TRADEOFFS 

•  INITIATE  SYSTEM  SOFTWARE  DEVELOPMENT 

•  DEVELOP  AND  VALIDATE  SYSTEM  SIMULATION 

•  DEVELOP  ALLOCATED  BASELINE  CONFIGURATION  SPECIFICATION 

•  PREPARE  INITIAL  SYSTEM  DOCUMENTATION  (LEVEL  1) 

•  PROPOSE  RFP/SOW  FOR  PHASE  II,  FULL-SCALE  DEVELOPMENT  INCLUDING  TRANSITION  TO 
PRODUCTION 

•  REVIEW  AND  SUPPORT  OF  CONTRACTORS  EFFORTS 

•  SUPPORT  FOR  GFE  ITEMS 

•  TECHNICAL  REVIEW  OF  PROGRESS  AND  SUBSYSTEMS 

•  ESTABLISH  TECHNICAL  TEAM 

•  SUPPORT  FACILITIES  OF  GOVERNMENT  RANGES/LABS  AS  REQUIRED 

•  UPDATE  TEMP  (WITH  COMOPTEVFORI 

•  factory  to  target  sequence 

•  ENVIRONMENTAL  PROFILE  REPORT 

•  VALIDATE  THROUGH  DEMONSTRATION: 

•  CONCEPT  (SI  CAN  SATISFY  MISSION  NEED 

•  SUFFICIENT  INFORMATION  TO  RESOLVE  CRITICAL  ISSUES 

•  CONDUCT  TRADEOFF  ANALYSIS  OF  COMPETITIVE  SYSTEMS 

•  COMPARE  TO  EXISTING  SYSTEMS.  THOSE  IN  DEVELOPMENT  ELSEWHERE 

•  EVALUATE  ALTERNATIVES  TO  A  NEW  START  TO  MEET  MISSION  NEED 

•  REAFFIRM  NEED 

•  MILESTONE  REVIEW  DOCUMENTATION  (MRD)  FOR  MILESTONE  II 

•  PROCESS  MRD  THROUGH  DECISION  AUTHORITY  REVIEW 

•  PREPARE  FOR  FULL-SCALE  DEVELOPMENT  PHASE 

•  CONTRACT  NEGOTIATIONS 

•  PROGRAMMING  AND  BUDGETING 

•  LONG  LEAD-TIME  ITEMS/MATERIALS/FACILITIES 


TRACE  TOTAL  RISK  ASSESSING  COST  ESTIMATE  METHODOLOGIES  IS  DISCUSSED  IN  SECTION  3. 


FIGURE  3-9.  D8.V  Phase  Duties  and  Outputs 


mined  by  the  decisions  made  in  the  D&V  Phase,  the  cost/risk/performance 
trade-offs  made  during  this  phase  will  have  a  marked  impact  on  LCC. 
Therefore,  it  is  generally  desirable  to  maintain  design  competition  at 
least  up  to  the  Milestone  II  decision  point. 


Objective  of  the  D&V  Phase 

At  Milestone  I,  the  PDA  will  have  reaffirmed  the  mission  element 
need  and  approved  the  selection  of  one  or  more  alternative  concepts  for 
demonstration.  At  that  point  the  PM  should  reexamine  and  clearly  iden¬ 
tify  the  program  goals  and  objectives  in  the  light  of  the  decision 
memorandum. 

The  broad  objective  of  the  D&V  phase  is  to  identify  the  system 
concept (s)  having  the  greatest  potential  for  meeting  the  mission  need  in 
a  cost-effective  manner.  This  will  require  the  PM  to  complete  a  number 
of  tasks  that  include: 

1.  Reviewing  guidance  received  from  higher  authority  during  and 
as  a  result  of  the  Milestone  I  review  process  for  any  change 
in  direction. 

2.  Ascertaining  that  the  technology  base  is  sufficiently  mature 
to  meet  the  system  needs  and  to  warrant  proceeding  into  FSD. 

3.  Resolving  all  critical  issues  that  were  identified  in  the 
Concept  Exploration  Phase  and  through  the  numerous  pre-Mi le- 
stone  I  reviews. 

4.  Providing  an  assessment  of  each  of  the  selected  alternatives 
evaluated  during  the  D&V  Phase  for  LCC  (including  logistic 
suppcrtability),  probable  mission  effectiveness,  and  risks  in 
sufficient  detail  to  support  a  selection  decision. 

5.  Completing  system  and  subsystem  documentation  to  the  extent 
necessary  to  support  contracting  for  the  FSD  Phase. 


Status  Reporting  during  the  D&V  Phase 

In  addition  to  NSATS,  discussed  earlier,  and  after  the  Milestone  I 
thresholds  have  been  established,  the  PM  may  oe  required  to  submit  a 
Program  Management  Proposal  (PMP). 


Program  Management  Proposal  (PMP).  The  Secretary  of  the  Navy 
(SECNAV)  has  established  program  stability  as  an  essential  element  in 
Program  Objectives  Memorandum  (POM)  and  oudget  formulation,  particularly 
for  the  ACAT  I  and  II  programs  which  together  account  for  the  majority 
of  Department  of  the  Navy  (DON)  RDT&E  and  procurement  resources.  These 
and  other  specified  programs  are  required  to  submit  PMPs  twice  yearly 
between  the  initial  POM  submittal  in  the  spring  and  the  President's 
budget  in  the  winter  (even  if  no  changes  arc  made  in  thresholds),  and  as 
needed  thereafter  if  the  change  would  affect  the  DON  budget. 
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o  A  change  that  alters  program  cost,  quantity  or  schedule 

o  A  change  in  system  capabilities,  such  as  range,  payload,  or 

speed 

o  A  change  that  alters  Navy  support  costs,  such  as  manpower- 

requirements  or  support  equipment 

A  PMP  Review  Board,  chaired  by  the  Director,  DON  Program  Informa¬ 
tion  Center  (DONPIC),  has  been  established  as  a  clearinghouse  for  out- 
of -cycle  PMPs.  Current  directions  for  the  PMP  process  are  given  in 
DONPIC  memo  Ser  902/327235  of  23  March  1982  or  can  be  obtained  from  0P- 
9C2 

Acquisition  Strategy  Update 


The  acquisition  strategy  should  be  checked  to  ensure  that  it  fol¬ 
lows  the  guidance  received  from  higher  authority  during  the  Milestone  I 
review  and  approval  and  with  NA/MATINST  5000.29.  Specifically,  the  PM 
should  see  that  the  acquisition  strategy  facilitates  making  and  evaluat¬ 
ing  interrelated  decisions  before  action  is  initiated.  The  acquisition 
strategy  should  be  broadbased  and  topically  parallel  to  the  IPS. 

Functional  Implementation  Plans  (TIPs).  The  PM  must  prepare  and 
regularly  update  the  FIPs  which  implement  the  approved  acquisition 
strategy.  Among  the  FIPs  required  on  most  programs  are  those  covering 
contracting,  life-cycle  cost  (LCC),  configuration  management,  data  man¬ 
agement,  integrated  logistic  support  (ILS),  maintenance  and  support, 
reliability,  safety,  test  and  evaluation,  and  training. 


Organ i zing  D&V  Phase  Activities 

Once  the  PM  has  updated  the  acquisition  strategy  and  reviewed  the 
functional  implementation  plans,  he  should  review  his  management  system 
for  planning,  staffing,  budgeting,  directing,  and  monitoring  the  requir¬ 
ed  tasks.  To  do  this,  he  should  obtain  or  develop  the  following: 

1.  A  checklist  of  phase  activities  and  events.  This  list  will 
include  the  activities  shown  in  Figure  3-8  but,  being  program-specific, 
will  usually  be  in  greater  detail. 

2.  A  detailed  set  of  documentation  requirements  (program  and  sys¬ 
tem)  , 

3.  An  updated  file  of  all  directives  and  instructions  that  con¬ 
tain  requirements  for  the  program  and  system  (see  system  acquisition 
instruction  and  specification  tree  at  the  end  of  Section  4). 

4.  An  updated  program  organization  chart  with  program  members' 
names,  locations,  and  precisely  delineated  areas  of  responsibility. 
This  should  be  made  available  to  program  members  and  to  contractors  and 
other  who  have  business  with  the  program  management  organization. 
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5.  A  survey  of  the  program  interfaces  with  other  organizational 
elements  that  identifies  points  of  contact  and  defines  the  responsibili¬ 
ties  of  each  as  they  relate  to  the  program. 

6.  A  list  and  graphical  representation  of  objectives,  milestones, 
and  time/task  budget  projections  for  the  entire  phase. 

7.  A  schedule  for  submitting  the  required  budgetary  documents  and 
a  calendar  of  the  PPBS  process  showing  the  status  of  program  elements 
supporting  the  program. 

8.  A  careful  identification  of  the  persons  and  offices  above  the 
PM  that  support  and/or  influence  the  program,  the  type  of  information 
they  need,  and  a  plan  for  its  timely  submission. 


Solicitation 


Navy  acquisition  practice  permit  and  encourage  the  use  of  a  single 
solicitation  for  the  entire  acquisition  process,  from  disclosures  of 
alternative  concepts  through  full-scale  development  and  initial  produc¬ 
tion. 


Proposals  that  included  the  contractors'  cost  estimates  for  the  D&V 
Phase  effort  should  have  been  required  in  the  solicitation  for  the 
concept  exploration  effort.  The  items  included  in  the  SOW  will  vary 
significantly  from  concept  to  concept  depending  both  on  the  proposed 
system  and  the  nature  of  the  demonstrations  and  evaluations  required  to 
validate  the  concept.  Some  areas  that  should  specifically  treated  in 
the  D&V  Phase  are:  use  environment;  cost  estimating  and  data  require¬ 
ments;  and  system  specification  and  documentation  requirements. 

The  solicitation  should  contain  specific,  realistic  goals  for  ILS, 
safety  requirements,  reliability  and  maintainability,  manning  personnel 
and  training,  and  other  factors  that  bear  on  a  proposed  system's  usa¬ 
bility  and  cast. 

The  solicitation  should  require  that  a  contractor  identify  and 
justify  any  high-risk  technology  incorporated  in  his  concept,  include 
specific  plans  for  the  reduction  of  risk,  and  discuss  alternatives  to 
the  high-risk  approach. 

Finally,  the  solicitation  should  require  that  each  contractor  sub¬ 
mit.  a  proposal,  including  costs,  for  a  Full-Scale  Development  (FSD) 
Phase  contract  prior  to  the  conclusion  of  the  D&V  Phase. 


Program  Manager's  ( PM 1 s )  Effort 

The  PM  must  see  that  there  is  sufficient,  factual  information 
generated  during  the  D&V  Phase  to  permit  an  intelligent  selection  of  the 
best  of  the  competing  concepts.  He  must  develop  (independently,  but 
with  appropriate  contractor  inputs)  the  TEMP,  the  ILS  Plan  (ILSP),  the 
Navy  Training  Plan  (NTP),  plans  for  manpower,  personnel  and  training 
support  (MP&TS),  indept?Hent  program  plan,  mission  profile  definition. 
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and  system  software  definition.  The  PM  must  also  oversee  the  demonstra¬ 
tion  program  and  conduct  trade-off  analyses  of  the  competitive  systems 
(these  subjects  are  discussed  in  more  detail  in  Section  4,  Critical 
Topics).  The  PM  may  also  find  it  necessary  to  initiate  parallel  or 
back-up  in-house  Navy  technology  efforts  to  determine  alternative  means 
for  dealing  with  identified  high-risk  areas  and  develop  system  software. 
A  large  part  of  the  PM's  time  and  effort  will  be  spent  in  active  liaison 
with  NAVMAT,  OPNAV,  SECNAV  and  OSD,  informing  them  of  the  program's 
progress  and  possible  problems,  and  justifying  the  program  funding  and 
objectives. 


Planning  for  the  Full-Scale  Development  (FSD)  Phase 

Issues  that  the  PM  and  his  team  will  want  to  consider  in  updating 
the  acquisition  strategy  and  planning  for  the  FSD  Phase  include: 

1.  Level  of  contractor  tasking  during  government-decision  periods 

2.  Support  and  facilities  (both  government  and  industry)  that 
will  be  needed  in  the  FSD  and  Production  Phases 

3.  Possible  changes  of  the  threat  and  revalidation  of  the  need 

4.  Proposed  system  performance,  readiness  time,  and  cost  thres¬ 
holds 

5.  High-risk  technology  or  new  manufacturing  procedures  that  may 
require  extra  attention  during  the  FSD  Phase 

6.  Identification  of  potential  long  lead-time  items 

7.  Analysis  of  subsystems  and  components  for  possible  breakout 
for  competitive  procurement  or  provision  as  government-furn¬ 
ished  material  (equipment)  (GFM/GFE) 

8.  Type  of  contracts  for  FSD  Phase  and  first  volume  production 

9.  Costs  to  be  incurred  if  competition  reinstated  for  production. 

10.  Degree  of  concurrency  for  engineering,  prototype,  and  pilot- 
production  subphases  and  the  extra  attention  necessary  to 
manage  concurrency 

11.  Task  planning  and  development  of  the  Work  Breakdown  Structure 
(WBS)  and  associated  costing  and  cost  control /reporting 

12.  T&E  continuation 

13.  Preplan  for  transition  to  production  (pilot  production) 

14.  Preplan  for  Production  and  Deployment  Phase. 


Monitoring 


The  process  of  assessing  technical  accomplishment,  identifying 
alternatives,  and  making  the  requisite  decisions  can,  at  times,  be 
rather  subjective,  reflecting  “engineering  judgment".  To  minimize  any 
possible  adverse  effects  of  such  judgments,  it  is  important  to  have  an 
independent  assessment  of  the  accomplishment  and  its  consequences  by 
technically  competent  personnel.  This  needs  to  be  done  whether  the 
accomplishment  is  the  result  of  in-house  or  contractor  effort;  however, 
it  is  especially  critical  for  contractor -performed  effort  since  contrac¬ 
tor  incentives  are  generally  different  than  government  incentives,  and 
the  contractor's  understanding  of  government  requirements  and  priorities 
may  be  imperfect.  Normally,  the  Defense  Contract  Administration  Service 
(DCAS),  Navy  Plant  Representative  Office  (NAVPRO)  or  Air  Force  Plant 
Representative  Office  { AFPRO)  are  not  staffed  for  this  function  to  the 
depth  required  (both  in  numbers  and  in  specialized  technical  knowledge), 
monitoring  capability  is  most  often  found  in  the  Navy  in-house  R&D 
laboratories/centers.  If  such  an  assignment  is  to  be  made,  it  needs  to 
be  made  prior  to  the  start  of  any  contract  effort.  Responsibility  and 
authority,  assignments,  delegations  and  the  precise  nature  of  the  moni¬ 
toring  task  need  to  be  defined  carefully  and  formally  and  explicitly 
established  that  the  authority  delegated  to  the  technical  monitoring 
activity  must  be  explicitly  stated  and  commensurate  with  the  responsi¬ 
bility  assigned,  if  that  activity  is  to  be  held  accountable  for  the 
discharge  of  that  responsibility. 

Two  negative  features  are  associated  with  the  assignment  of  the 
monitoring  function.  First,  it  generally  increases  costs.  This  should 
be  recognized  and  provided  for.  Second,  in-house  talent  may  try  to 
assume  control  of  the  engineering  effort.  The  best  engineering  judg¬ 
ments  sometimes  differ,  and  the  PM  may  sometimes  have  to  overrule  the 
in-house  monitor.  Overall,  though,  the  PM  and  his  program  are  better 
off  for  this  monitoring  function  than  if  it  were  not  used. 


MILESTONE  II 

The  second  major  decision  is  program  go-ahead  and  approval  to 
proceed  with  FSD.  The  timing  of  the  Milestone  II  decision  is  flexible 
and  depends  upon  the  tailored  acquisition  strategy  approved  by  the  PDA 
at  Milestone  I.  NOTE:  The  delayed  Milestone  II  option  of  DODD  5000.1 
will  normally  not  be  used  for  DQN-directed  programs. 


Milestone  II  Review  Documentation  (MRP) 

The  MRD  for  Milestone  II  is  the  same  as  for  Milestone  I  (see  page 
3-18)  except  for  ACAT  I  programs.  Instead  of  the  SCP,  ACAT  I  programs 
require  a  Decision  Coordinating  Paper  (DCP)  and  a  TEMP.  In  certain 
cases  the  DAE  may  also  require,  for  an  ACAT  I  program,  the  preparation 
of  an  Integrated  Program  Summary  (IPS)  when  he  feels  that  the  informa¬ 
tion  contained  in  the  DCP  requires  expansion.  ACAT  II  programs  require 
the  submission  of  an  NDCP  and  TEMP  and  ACAT  III  and  IV  programs  require 
the  submission  of  a  TEMP.  The  NDCP  and  TEMP  were  described  previously 
in  the  discussion  of  documentation  needed  for  Milestone  I  review. 
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Decision  Coordinating  Paper  (DCP).  The  DCP  is  a  top-level,  issue- 
oriented  summary  document  that  identifies  alternatives,  goals  and  thres¬ 
holds,  and  cost.  The  DCP  summarizes  the  Navy's  acquisition  planning  for 
the  system's  life-cycle  and  provides  a  management  overview  of  the  pro¬ 
gram.  It  is  limited  to  18  pages,  excluding  annexes. See  DODI  5000.2  for 
the  required  DCP  format. 

Integrated  Program  Summary  (IPS).  The  IPS  does  not  repeat  informa¬ 
tion  contained  in  the  DCP  but  provides  more  specific  information  and  a 
comprehensive  summary  of  the  program.  When  further  detail  is  available 
in  published  documents,  those  documents  are  referenced  in  the  IPS.  When 
possible,  display  material  is  in  numerical  or  tabular  form.  The  IPS 
should  not  be  classified  higher  than  Secret.  The  DCP  and  IPS,  if  re¬ 
quired,  provide  different  levels  of  detail  for  consideration  by  the 
DSARC  at  Milestone  II  and  Milestone  III.  It  is  limited  to  30  pages 
including  all  attachments.  See  DODI  5000.2  for  the  required  IPS  format. 


Milestone  II  Review  and  Approval 

The  review  and  approval  process  for  Milestone  II  is  basically  the 
same  as  for  the  Milestone  I,  as  described  earlier  and  in  Appendix  A. 


Significance  of  Milestone  II 


Approval  by  the  PDA  reaffirms  the  Navy's  commitment  to  fund  the 
expensive  FSD  Phase.  The  FSD  Phase  usually  includes  a  pilot  production 
subphase  where  the  production  line  is  established,  using  RDT&E  funds,  to 
produce  test  articles  for  TECHEVAl  and  0PEVAL.  Except  for  long  lead 
time  items  (which  can  be  approved  at  the  PDA  program  review),  production 
funds  (APN,  0PN,  SCN)  can  not  be  used  to  buy  articles  until  a  Milestone 
III  ALP/AFP  is  approved.  Approval  at  Milestone  II  is  also  a  commitment 
by  DON  to  produce  and  field  the  system.  Included  in  the  approval  is  the 
selection  of  the  system  design  and  the  establishment  of  firm  schedule, 
cost,  and  capability  thresholds. 


Ship  Acquisition.  Ship  development  and  acquisition  will  follow  a 
procedure  tailored  to  the  individual  design.  In  typical  ship  acquisi¬ 
tion  programs,  Milestone  II  will  authorize  lead-ship  construction  and 
Milestone  III  will  authorize  follow-ship  construction  as  shown  in  Figure 
1-5  in  Section  1. 


Program  Stability.  Private  and  public  figures  are  concerned  with 
the  cost  growth  associated  with  weapon  acquisitions.  Congressional 
scrutiny  becomes  particularly  acute  not  only  at  the  time  of  initial  and 
ongoing  annual  appropriations,  but  also  when  a  new  weapon  system  expe¬ 
riences  slow  development,  cost  overruns,  delays  in  fielding,  or  ques¬ 
tionable  performance.  The  scrutiny  is  even  more  intense  when  these 
problems  are  attributable,  at  least  in  part,  to  unrealistic  inflation 
estimates,  poor  cost  estimates,  program  stretch-outs,  changes  in  weapon 
systems  specifications,  inadequate  budgeting,  lack  of  competition,  high 
risk  system  design,  or  poor  management. 


The  schedule,  cost  and  performance  thresholds  established  at  Mile¬ 
stone  II  are  to  be  kept.  Upward  deviation  from  these  established  thres¬ 
holds  may  jeopardize  the  continuance  of  the  program.  While  all  PMs  are 
required  to  keep  their  programs  on  schedule,  the  ACAT  I  and  II  programs 
come  under  special  attention  because  of  their  very  large  LCC.  In  short, 
"If  you  want  to  get  your  boss'  attention,  break  threshold." 


FULL-SCALE  DEVELOPMENT  (FSD)  PHASE 

Milestone  II  marks  the  beginning  of  the  FSD  Phase  -  a  period  of 
careful,  iterative,  detailed,  and  therefore  expensive,  engineering  ef¬ 
fort.  The  final  product  of  this  phase  is  a  product  baseline  configura¬ 
tion  design  and  a  documentation  package  that  reflect  the  established 
cost,  schedule,  logistic  supportability,  and  performance  constraints. 
The  phase  is  usually  conducted  in  three  partially  overlapping  subphases: 
engineering,  prototype,  and  pilot  production.  Figure  3-10  is  an  over¬ 
view  of  the  inputs,  principal  activities,  and  outputs  of  the  FSD  Phase. 

The  various  subphases  of  the  FSD  Phase  referred  to  here  are  charac¬ 
teristics  of  good  engineering  practice.  They  are  not  part  of  the  offi¬ 
cial  lexicon  of  the  systems  acquisition  process  as  defined  in  DODD 
5000.1.  Under  the  existing  system,  difficulty  is  often  encountered  in 
making  the  transition  from  development  to  production.  One  reason  is 
that  DODD  5000.1  treats  the  transition  as  a  step  function  occurring  at 
Milestone  III,  rather  than  as  a  ramp  function.  As  a  result,  comptrol¬ 
lers  are  reluctant  to  allow  the  use  of  production  money  for  the  develop¬ 
ment  of  hard  tooling  and  production  facilities  prior  to  the  official 
Milestone  III  go-ahead. 

Proposals  have  been  made  to  establish  an  interim  milestone,  prior 
to  the  start  of  the  pilot-production  subphase,  for  the  purpose  of 
freeing  production  dollars.  This  could  be  done  provided  that  the  interim 
milestone  is  called  for  in  the  acquisition  strategy  and  significant 
portions  of  the  design  have  matured,  the  product  baseline  has  been 
documented,  and  contractor  planning  for  production  (including  reliabili¬ 
ty,  quality  assurance,  etc.)  is  ready  for  implementation.  A  formal 
review  and  approval  by  the  appropriate  PDA  would  be  necessary  at  this 
time  to  commence  limited  or  pilot  production.  The  purpose  of  this 
proposed  additional  milestone  is  to  facilitate  the  transition  to  produc¬ 
tion;  extra  planning  and  care  by  the  PM  would  be  necessary  to  prevent 
disruption  of  the  program  while  preparing  for  the  review. 


Objectives  of  the  FSD  Phase 

The  objective  of  the  FSD  Phase  is  the  demonstration  and  documenta¬ 
tion  of  a  cost-effective,  operationally  suitable,  reliable,  and  main¬ 
tainable  production-engineered  system  that  meets  the  mission  need.  At 
the  outset  of  the  phase,  the  PM  should  re-examine  the  specific  program 
objectives  to  ensure  that  they  reflect  the  guidance  set  forth  in  the 
Milestone  II  SDDM/SNDM/SPRDD/DADM. 


3-36 


FULL  SCALE 

development 

phase 


(ENGINEERING  DEVELOPMENT 
TEST  AND  EVALUATION! 


PRINCIPAL  ACTIVITIES 


•  MILESTONES  MRO 

•  ACO  STRATEGY  STRATEGY 

•  COMP  VS  NON-COMP 

PROO 

•  TYPE  OF  CONTRACT 

•  APPROVED  TEMP 

•  ILS  PLAN 

•  DRAFT  NAVY  TNG  PLAN  (NTP) 

•  SYSTEM  SAFETY 

PROGRAM  PLAN 

•  SINGLE  CONCEPT 

SELECTEO 

•  CRIT  SUBSYSTEM 

VALIDATED 

•  MILITARY  UTILITY/ 

OPERATIONAL  EFFECTIVE¬ 
NESS  ESTABLISHED 

•  ALLOCATED  FUNCTIONAL 

BASELINE  (SYSTEM, 
SUBSYSTEM  SPECS) 

•  CRITICAL  RISK  AREAS 

DEFINED 

•FOLLOW-ON  PROPOSAL 
NEGOTIATED 

•  SYSTEM  SOFTWARE 

SUPPORT  AGENCY 
SELECTED 

•  ALTERNATIVE  MAINTENANCE 

CONCEPTS  CONSIDERED 

•  DECISION  MEMORANDUM 

DOCUMENTING  MILESTONE  II 

•  REAFFIRM  NEEO 

•  AUTHORIZE  FULL  SCALE 

DEVELOPMENT 

•  AUTHORIZE  PILOT 

PRODUCTION  FOR  OPEVAL 

•  INTENTION  TO  DEPLOY 

SYSTEM 

•  THRESHOLDS  ESTABLISHED 

•  SCHEOULE 
•COST 

•LOGISTIC  SUPPORT  ABILITY 

•  PERFORMANCE 

•  APPROVES  EXCEPTIONS 

TO  ACO  POLICY 


ENGINEERING 

MRO  PREPARE 

HLT 

DELIVERY 

1 

ACQ  STRAT/IMPLEMENT  PLANS 


PRO  MGMT  (LIAISON,  PPBS.  MONITOR.  POLITICS) 


ENG  TEST  AND  EVAL 


TAAF 


*  SARi 

* 


PROTOTYPE 


HLT 


j 


DELIVERY 


*  I 

*! 


DTS.I 


eyYeCH 

&L-.WAL- 


TAAF 


RELIABILITY  &  MAINTAINABILITY  PROGRAM  PROR  A 


INTEGRATED  LOGISTIC  SUPPORT  PROGRAM  LRG  A 


"T 


MANNING,  PERSONNEL  AND  TRAINING 


•  PRODUCTION  BASELINE 

DOCUMENTATION  PACK 

•  OPERATIONAL  SUPPORT 

BASELINE 

•  VALIDATED  PRODUCTION 

FACILITY 

•  APPROVEO  FOR  FULL 

PRODUCTION  (AFPl 

•  ACQ  STRATEGY  UPDATED 

PROPOSED  PRODUCTION 
PLANS  UPOATEO 

•  RATE 

•  NEEO  FOR  SECOND 

SOURCE 

•  ESTIMATED  COST, 

SCHEOULE 

•  CONTRACTOR  PROPOSAL 

FOR  1ST  VOL  PROD 

•  PROPOSED  PROOUCT 

IMPROVEMENT  PROGRAM 

•deployment  plans 

•  MANPOWER,  PERSONNEL 

1  RAINING 

•  INTEGRATED  LOGISTIC 

SUPPORT 
•FACILITIES 

•  INTEGRATION  WITH 
EXISTING  SYSTEMS 

•  MILESTONES!  MRO 

•  MILESTONE  IN  DECISION 

MEMORANDUM 


AFP  -APPROVED  FOR  FULL  PRODUCTION 
AIT  -  ADMINISTRATIVE  LEAD  TIME 
COR  -  CRITICAL  DESIGN  REVIEW 
DCR  -  DESIGN  CERTIFICATION  REVIEW 

oue  -  development  test  and  evaluation 

HLT  -HARDWARE  LEAD  TIME 

LRG  -  LOGISTIC  REVIEW  GRQUF 
MRO  -MILESTONE  REVIEW  DOCUMENTATION 
POR  -PRELIMINARY  DESIGN  REVIEW 


PPBS  -  PLANNING,  PROGRAMMING  AND  BUDGETING  SYSTEM 
PPPI  -  PREPLANNED  PRODUCT  IMPROVEMENT 
PRDR  -  PREPROOUCTION  RELIABILITY  DESIGN  REVIEW 
PRR  -  PRODUCTION  READINESS  REVIEW 
Q  -  PRODUCT  QUALIFICATION 
SAR  -SELECTED  ACQUISITION  REPOR1  [QRTLYI 
TAAF  -  TEST  ANALYZE  ANO  FIX 
EMP  -  TEST  AND  EVALUATION  MASTER  PLAN 


FIGURE  3-10.  Inputs,  Activities,  Outputs  during  FSD. 
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Status  Reporting  during  the  FSD  Phase 

In  addition  to  NSATS  and  PMP  reporting,  discussed  earlier,  the  PH 
may  also  be  required,  after  Milestone  II,  to  prepare  additional  reports, 
as  follows: 

Selected  Acquisition  Reports  (SARs),  the  Nunn  Amendment  and  the 
Defense  Acquisition  Executive  Summary  (DAESK  SARs  are  quarterly  re¬ 
ports  to  Congress  that ’"summarize  the  status  and  cost  of  ACAT  I  programs 
that  have  reached  Milestone  II.  The  SAR  system  allows  routine  visibili¬ 
ty  of  major  defense  acquisition  programs  and  cost  trends  that  were  not 
previously  available  to  Congress.  Additional  unit  cost  reports  are 
required  by  Congress  (originally  as  part  of  the  DQD  Authorization  Act  of 
1982  -  the  “Nunn  Amendment").  This  requires  that  if  the  total  program 
acquisition  unit  cost  or  the  current  procurement  unit  cost  of  a  weapon 
system  exceeds  by  15%  the  March  1981  SAR  estimate  (So-called  "Nunn 
Busters"),  then  a  report  on  that  system  must  be  submitted  to  Congress  as 
well.  Also  when  program  unit  cost  or  the  current  procurement  unit  cost 
of  a  weapon  system  exceed  the  March  1981  SAR  estimate  by  25%,  SECDEF  is 
required  to  make  certifications  concerning  that  program  to  Congress.  If 
this  is  not  done,  authority  to  obligate  funds  for  that  program  is  auto¬ 
matically  terminated.  DOD  has  institutionalized  this  in  DODI  7220.31 
and  now  requires  a  periodic  unit  cost  report,  the  DAES,  on  all  ACAT  Is. 


Acquisition  Strategy  Update 

The  PM  should  conduct  a  comprehensive  review  of  the  acquisition 
strategy  and  FlPs  in  conjunction  with  a  review  of  the  Milestone  II 
decision  document.  The  acquisition  strategy  and  FIPs  should  be  adjusted 
to  accommodate  any  specific  instructions  from  the  decision  authority.  A 
review  of  the  program  management  system  is  also  in  order  at  this  time. 

Although  not  a  requirement,  it  is  a  good  idea  for  the  PM  to  give 
his  entire  management/support  team  an  in-depth  briefing  on  the  strategy 
to  be  employed  in  the  FSD  Phase.  The  briefing  should  include  a  review 
of  the  management  tools  available  and  their  status  and  include  a  discus¬ 
sion  of  the  following  items:  Work  Breakdown  Structure  (WBS),  LCC,  man¬ 
agement  review  and  checking  procedure,  risk  management,  competition  in 
production,  component  breakout  and  design  ownership. 

Organizing  the  FSD  Phase  Activities 

Concurrently  with  the  review  of  the  acquisition  strategy,  the  PM 
should  prepare  a  checklist  of  phase  activities.  This  will  help  him  to 
assess  the  program's  readiness  for  the  commitment  of  the  large  quantity 
of  RDT&E  dollars  required  for  the  FSD  effort.  The  checklist  will  vary 
significantly  from  program  to  program  but  should  address  the  considera¬ 
tions  enumerated  below. 

1.  System  Specification.  Review  the  system  specification  for 
incorporation  of  guidance  from  higher  authority  and  the  elimination  of 
unnecessary  constraints.  Determine  its  completeness  and  suitability  as 
the  governing  performance  requirement  document  for  the  FSD  Phase  effort. 
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2.  Development  Specifications.  Review,  for  correctness  and  cla¬ 
rity,  the  development  specifications  that  govern  the  individually  iden¬ 
tified  configuration  items. 

3.  Test  and  Evaluation  (T&E).  Expand  the  details  of  the  develop¬ 
ment  test  and  evaluation  ( DT&E )  program  including  determination  of  the 
data  requirements,  particularly  the  required  degree  of  accuracy.  It 
should  be  remembered  that  test  data,  without  a  documentation  package 
describing  the  design  tested,  are  worthless,  and  the  hardware/software 
must  be  built  to  applicable  approved  documentation  if  test  programs  are 
to  have  any  meaning.  Note  that  the  PM  must  establish  early  and  continu¬ 
ing  liaison  with  the  Operational  Test  and  Evaluation  Force  (OPTEVFOR)  to 
ensure  that  operational  test  and  evaluation  (OT&E)  requirements  are 
identified  and  integrated  into  the  program  with  proper  support  budget¬ 
ing.  The  PM  must  provide  COMOPTEVFQR  with  all  significant  DT&E  test 
data  and  analyses  that  will  assist  in  planning  or  interpreting  OT&E. 
OPTEVFOR  is  required  to  monitor  all  pertinent  phases  of  DT&E. 

4.  Integrated  Logistic  Support  (ILS).  Intensify  the  I LS  planning 
effort  to  ensure  suitable,  aggressive  input  to  the  design  evolution 
process  and  resultant  supportability. 

5.  Design  Documentation.  Arrange  for  in-process  reviews  of  de¬ 
sign  documentation  including  a  detailed  review  of  the  contractor's 
configuration  control  process.  Assign  responsibility  for  instituting 
the  corrective  action  required  to  ensure  compliance  with  the  documenta¬ 
tion  requirements.  The  corrective  action  is  probably  best  done  by  an 
agency  other  than  the  developing  contractor. 

6.  Personnel  Training,  Simulators  and  Training  Devices.  Plan  for 
the  attainment  and  maintenance  of  the  required  proficiency  for  operating 
and  support  personnel,  and  determine  the  scope  and  duration  of  on-the- 
job,  simulator,  and  formal  training  requirements.  Identify  anticipated 
savings  from  use  of  simulator  or  other  training  devices.  The  develop¬ 
ment  of  simulators  and  training  devices  must  proceed  on  a  schedule  that 
will  make  them  available  to  train  Fleet  personnel  for  OPEVAL  and  IOC. 

7.  Other  Considerations,  Ensure  that  the  Phase  II  plans  address: 

o  How  to  maintain  program  stability  and  continuity  while  await¬ 
ing  results  of  TECHEVAL,  OPEVAL,  and  program  reviews. 

o  The  use  of  foreign  products  and/or  parts  and  material. 

o  Planning  for  the  procurement  of  long  lead-time  hardware  items 
and  tools,  the  stockpiling  of  critical  material,  and  the 
acquisition  or  preparation  of  special  manufacturing  and  sto¬ 
rage  facilities. 

o  Competitive  second-source  procurement  potential. 

o  The  effects  of  possible  variations  in  production  rates  on  unit 

cost  and  how  these  can  be  kept  within  acceptable  thresholds. 
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Engineering  Subphase 


The  engineering  subphase  features  a  design-build-test-redesign 
iteration  of  engineering  development  models  (EDM)  to  evolve  component, 
equipment,  subsystem,  and  system  designs  that  meet  the  requirements  of 
the  allocated  baseline  configuration.  The  EDMs,  developed  during  a 
program's  FSD  Phase,  are  "flyable"  and  will  be  extensively  tested  to 
ensure  that  functional  and  technical  objectives  can  be  achieved.  The 
models  are  used  to  demonstrate  that  tactical  performance  capability  of 
the  system  under  typical  operational  conditions,  as  well  as  to  establish 
the  hardware  design  baseline. 

In  this  subphase,  system  attributes  such  as  reliability,  maintaina¬ 
bility,  safety,  supportability,  etc.,  are  established  by  the  design.  It 
is  very  important  that  the  PM  have  these  characteristics  established  and 
their  adequacy  verified  during  this  subphase  since  downstream  changes 
will  be  very  expensive.  When  completed,  this  subphase  will  have  defined 
and  documented  a  product  design  disclosure  which  can  be  used  in  the 
fabrication  of  the  first  prototype  models  of  the  following  subphase. 
Listed  below  are  matters  that  the  PM  must  be  aware  of,  plan  for,  and 
carefully  oversee.  He  should  develop  his  own  specific  actions  to  ad¬ 
dress  each  item. 

o  Fabricate  engineering  development  models 

o  Expand  the  WBS  to  required  levels 
o  Refine  subsystem  development  specifications 

o  Develop  preliminary  support  equipment  design 

o  Update  ILS  requirements 

o  Update  functional  implementation  plans 

o  Update  cost  goals 

o  Update  system  simulation 

o  Develop  document  control  plan 

o  Implement  test  and  evaluation  plan 

o  Perform  reliability  and  maintainability  analyses 

o  Confirm  that  the  design  meets  human  engineering  goals 

o  Verify  external  interfaces 

o  Confirm  survivability  enhancement  features 

c  Confirm  susceptibility  reduction  features 

o  Confirm  reliability  and  maintainability  features 

o  Detail  the  prototype  design 

o  Prepare  level -2  documentation 

o  Implement  uniform  closed-loop  failure  reporting  analysis  and 
corrective  action  system 

o  Prepare  preliminary  producibility  assessment 

o  Conduct  preliminary  design  review. 


Prototype  Subphase 

In  the  prototype  subphase,  the  system  evolved  during  the  preceding 
engineering  subphase  will  be  further  refined.  The  subphase  features  a 
build-test-modify/redesign-build-test  iteration.  From  this  iteration,  a 
design  disclosure  will  develop  that  describes  a  physical  and  functional 
equivalent  of  the  product  expected  to  be  produced  for  service  use.  The 
final  units  delivered  under  this  program  together  with  the  results  of 
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the  iterative  process  will  provide  the  test  items  required  for  TECHEVAL. 
Final  decisions  affecting  the  design  are  based  upon  the  results  of  the 
TECHEVAL.  The  documentation  package  released  to  pilot  production  must 
include  all  critical  process  specifications,  inspection  procedures,  and 
all  other  instructions  necessary  for  successful  manufacture  of  the  pilot 
production  models.  Listed  below  are  activities  that  the  PM  should  be 
aware  of  and  provide  for: 

o  Fabricate  the  proper  number  prototype  models 
o  Integrate  system  software 

o  Complete  design  and  fabrication  of  support  equipment  models 
o  Conduct  test  and  evaluation 

o  Test,  analyze,  and  fix  (TAAF) 

o  TECHEVAL 

o  Conduct  system  qualifications  program:  environmental, 

safety,  vulnerability,  initial  reliability,  and  nonstan¬ 
dard  parts 

o  Complete  production  facility 

o  Update  cost  goals 

o  Develop  support  facilities 

o  Complete  logistic  plans 

o  Training  (final  and  for  OPEVAL) 

o  Complete  technical  data  compilation 

o  Develop  production  design 

o  Provide  level -2  or  -3  documentation 

o  Develop  product  baseline  configuration  specification 
o  Conduct  production  readiness  review 

o  Update  system  simulation 

o  Provide  initial  support  equipment 

o  Design 

o  Long-lead  procurement 

o  Conduct  critical  design  review  (CDR)  as  basis  for  release  to 
pilot  production 

Among  the  critical  issues  to  be  address  during  the  prototype  sub¬ 
phases  are: 

1.  Quality  Assurance  (QA).  QA  provisions  must  be  spelled  out  if 
their  efficiency  is  to  be  verified  in  the  pilot-production  subphase. 
These  include  any  requirements  for  special  incoming  or  in-process  in¬ 
spections  or  any  specific  data  requirements  or  test  necessary  to  ensure 
the  quality  of  the  end  product.  However,  as  indicated  in  Section  4, 
"Quality,"  specific  data  and  tests,  per  se,  cannot  assure  the  quality  of 
a  product  -  these  must  be  designed  in. 

2.  Rework  Philosophy.  Repair  procedures  for  any  faulty,  in- 
process  equipment  and  any  unique  Material  Review  Board  (MRB)  require¬ 
ments  should  be  defined  in  the  prototype  subphase  so  that  they  can  be 
verified  in  the  pilot-production  subphase. 

3.  Configuration  Management.  Configuration  control  and  the  ap¬ 
proval  procedures  for  baseline  configuration  design  changes  should  be 
fully  evolved  by  the  start  of  the  prototype  subphase.  While  configura¬ 
tion  control  should  nor  be  so  cumbersome  as  to  hinder  progress,  it 
should  be  elevated  to  program-management-office  level  at  the  Start  of 
TECHEVAL. 
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4.  Reliability  and  Maintainability.  Design  attributes  affecting 
the  systems  reliability  and  maintainability  should  have  been  incorporat¬ 
ed  in  the  basic  system  design  before  and  during  this  subphase.  A  good 
system  for  closed-loop-failure  reporting,  analysis,  and  corrective  ac¬ 
tion  should  also  have  been  established. 


Pilot-Production  Subphase;  the  Transition  to  Production 

The  purpose  of  the  pilot-production  subphase  is  to  exercise  the 
system  hardware  and  software  design  disclosures,  and  the  data  package 
evolved  during  the  prototype  subphase,  in  the  production  environment. 
During  this  subphase  the  system,  using  R&D  funds,  will  be  made  with 
production  hard  tooling,  using  production  processes  and  procedures,  and 
inspected  with  production  test  equipment  in  accordance  with  applicable 
instructions.  Documentation  of  test  and  inspections  procedures  must  be 
adequate  to  control  quality  at  the  vendor's  plant. 

The  hardware  and  software  items  that  are  produced  during  the  ini¬ 
tial  stage  of  this  subphase  are  evaluated  to  determine  the  existence  of 
degradation  resulting  from  the  production  processes  and  procedures  and 
to  provide  a  basis  for  correction.  Successive  systems  will  provide  the 
test  articles  required  for  the  formal  OPEVAL  conducted  by  the  indepen¬ 
dent  test  agency  (OPTEVFOR  or  MCOTEA).  A  successful  OPEVAL  is  requi rea 
for  CNO  approval  for  full  production  (AFP)  and  support  of  the  major 
production  decision  (Milestone  III).  Any  remaining  systems  can  be  used 
to  help  provide  the  IOC. 

Continuity  of  the  production  effort  should  be  considered  at  +his 
time.  Beginning  with  the  prototype  program,  the  contractor  should 
establish  a  production  capability  by  training  key  personnel  in  the 
special  processes  and  procedures  that  are  unique  to  the  manufacture  of 
the  item.  As  the  knowledge  and  capability  of  these  people  increase,  the 
quality  of  the  product  also  increases.  If  this  quality  is  to  be  retain¬ 
ed,  it  is  essential  that  the  key  employees  be  involved  in  the  production 
effort  on  a  continuing  basis  lest  they  be  transferred  to  other  projects. 
This  threat  to  product  quality  through  reduction  in  expertise  may  be 
prevented  by  arranging  for  the  pilot-production  line  to  continue  to 
produce  at  a  minimum  sustaining  rate  until  the  initial  volume  production 
effort.  If  pilot  production  were  halted  when  the  articles  needed  for 
contractor  qualification  and  OPEVAL  were  delivered,  some  portions  of  the 
production  line  would  be  idle  for  a  considerable  period.  Keeping  the 
same  key  people  on  the  job  and  busy  by  extending  the  pilot  production 
run  ensures  that  the  hardware  delivered  for  service  use  under  the  ini¬ 
tial  volume  production  contract  will  be  on  the  same  learning  curve  and, 
hence,  of  at  least  as  good  a  quality  as  that  delivered  under  the  pilot- 
production  program.  This  option  is  available  to  ACAT  I  and  II  programs 
by  the  use  of  the  Milestone  I T I A  AlP  structure. 

Continuation  of  pilot  production  has  an  additional  advantage  in 
that  it  can  lead  to  an  earlier  IOC  than  would  otherwise  be  possible. 
However,  the  achievement  of  an  earlier  IOC  is  rarely  an  adequate  justi¬ 
fication  for  continuation  of  the  pilot  line  beyond  the  requirement  for 
T&E  hardware,  and  PDAs  will  generally  not  accept  it  as  such.  Unless 
there  is  overwhelming  need  arid  urgency,  sole  justification  for  continua- 


tion  of  the  pilot  line  rests  on  the  necessity  for  continuity  in  the 
production  effort  and  the  maintenance  of  a  steady,  uninterrupted  in¬ 
crease  in  the  quality  of  the  article  being  delivered. 

An  issue  that  must  be  resolved  prior  to  the  start  of  the  pilot- 
production  subphase  (if  a  Milestone  1 1 1 A  review  has  not  been  held)  is 
the  location  and  staffing  of  the  pilot  facility.  Large  contractors 
sometimes  develop  a  design  in  one  division  and  produce  the  product  in 
another  division  located  in  a  different  geographical  area.  It  should  be 
required  that  the  pilot  line  be  established  at  the  full-scale  production 
facility  and  that  it  be  staffed  by  personnel  with  the  same  qualifica¬ 
tions  and  job  classifications  as  those  who  will  staff  the  full-scale 
production  line. 

Whenever  production  is  transferred  from  one  division  of  a  company 
to  another,  those  divisions  react  to  the  design  as  would  a  new  manufac¬ 
turer  of  the  product  -  the  equivalent  of  "going  back  to  square  one".  If 
it  becomes  necessary  to  effect  such  a  transfer,  the  government  should 
require  that  a  preproduction  model  be  produced  by  the  new  division  and 
be  qualified  before  that  division  is  allowed  to  produce  for  the  service- 
use  inventory. 

Below  is  a  list  of  important  activities  which  should  be  provided 
for  during  the  pilot-production  subphase.  The  updated  functional  imple¬ 
mentation  plans  should  contain  a  more  detailed  cleanup  list  of  all 
development  actions,  tests,  documentation,  etc.,  that  remain  to  be 
completed  during  the  FSD  Phase. 

o  Fabricate  pilot-production  models 

o  Conduct  T&E 

o  Production  qualification  tests 
o  Reliability  and  maintainability  demonstration 

o  OPEVAL 

o  Validate  producibility 

o  Conduct  first  article  configuration  inspection  (FACI) 
o  Validate  manufacturing  screening  procedures 
o  Validate  acceptance  criteria 

o  Provide  hardware  for  OPEVAL 

o  Validate  Navy  training  procedures 

o  Validate  manuals 

o  Obtain  approval  for  full  production 

o  Update  production  design 

o  Provide  validated  full-scale  production  documentation 

o  Conduct  Production  Readiness  Review 

o  Conduct  preproduction  reliability  design  review  (PKDR) 
o  Initiate  P3I  program  (if  applicable) 

o  Commence  planning  of  successive  phases  of  P3I  or  product  im¬ 
provement  program  (PIP) 


Approval  for  Full  Production  (AFP)/Approval  for  Limited  Production  (ALP) 

The  Navy's  policy  of  requiring  an  approval  for  service  use  (ASU)  or 
one  of  its  related  lesser  designations  (provisional  approval  for  service 
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use  or  waiver  in  advance  of  ASU )  has  been  eliminated  in  order  to  stream¬ 
line  the  acquisition  process.  The  new  procedure  is  less  duplicative  and 
less  susceptible  to  misinterpretation  and  misuse.  The  purpose  of  the 
new  procedure  is  to  maintain  rigorous  control  of  the  production  decision 
and  thus  ensure  that  equipment  introduced  to  the  Fleet  is  effective, 
reliable,  maintainable,  and  supportable. 

At  Milestone  III,  the  appropriate  PDA  will  make  one  of  three  pro¬ 
duction  decisions  after  reviewing  appropriate  development,  reliability, 
test,  and  evaluation  data.  The  three  alternative  decisions  are: 

1 .  AFP 

2.  ALP  -  a  1-year  limited  quantity  approval 

3.  Not  approved  for  production 

Detailed  instructions  for  processing  the  AFP/ALP  can  be  found  in 
OPNAVINST  5000.42  and  NAVMATINST  5000.19. 

AFP  signifies  that  the  system  has  demonstrated,  through  TECHEVAL, 
the  meeting  of  its  technical  thresholds;  that  it  has  demonstrated, 
through  OPEVAL,  both  the  meeting  of  operational  thresholds  and  its 
operational  effectiveness  and  operational  suitability;  and  that  it  has 
shown,  through  ILS  audit,  that  support  planning  is  satisfactory.  No 
additional  development  work  or  corrective  action  is  required. 

ALP  signifies  that  the  system  --  although  not  yet  having  demon¬ 
strated  all  the  capabilities  required  for  AFP  --  has  undergone  Initial 
phases  of  DT&E,  OT&E  and  personnel/logistic  review  to  the  extent  that 
most  of  the  AFP  criteria  have  been  demonstrated;  COMOPTEVFOR  has  assess¬ 
ed  the  system  as  being  potentially  operationally  effective  and  opera¬ 
tionally  suitable;  and  a  clear  plan  and  funding  exists  for  completion  of 
development  or  corrective  action,  demonstration  of  meeting  remaining 
thresholds  and  being  logistically  certified  prior  to  the  next  year's 
production  decision  point. 

The  Navy  exercises  rigorous,  high-level  control  of  the  production 
approval  process  to  ensure  that  all  equipment  reaching  the  fleet  --  even 
that  from  the  earliest  production  lots  --  meets  the  intended  standards 
of  performance,  reliability,  maintainability  and  logistic  supportabi 1 - 
ity.  This  can  only  be  accomplished  by  paying  closest  attention  to 
actual  DT&E  and  OT&E  results  and  support  planning,  at  each  Milestone 
III. 


Ideally,  the  objective  of  the  Navy  acquisition  process  would  be  to 
have  all  systems  complete  development  and  demonstrate  meeting  all  tech¬ 
nical  and  operational  thresholds  through  full  TECHEVAL  and  OPEVAL,  and 
demonstrate  all  ILS  requirements,  prior  to  production  line  startup, 
which  would  be  accomplished  with  an  AFP  decision. 

This  objective  can  be  met  in  smaller  programs  (ACAT  IV  and  most  of 
the  ACAT  Ills);  however,  the  extensive  production  line  effort  required 
in  large  programs  (ACAT  I,  most  of  ACAT  II  and  a  few  ACAT  III)  require 
"transition  to  production"  phasing  using  ALP  for  the  initial  production 
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lot  (or  possibly  two  lots  in  the  case  of  extremely  large  ACAT  1  pro¬ 
grams)  . 

In  each  case  where  an  ALP  decision  is  required,  every  effort  should 
be  made  to  complete  development  work  or  corrective  action  and  demon¬ 
strate  the  meeting  of  all  thresholds  through  DT&E  and  OT&E  prior  to  the 
next  year's  AFP/ALP  decision  point.  If  there  is  doubt  at  Milestone 
1 1 1 A ,  startup  of  production  should  be  delayed  rather  than  risk  several 
years'  production  under  ALP. 

Similarly,  any  ALP  decision  should  cause  the  decision-maker  to  give 
strong  consideration  to  reprogramming  RDT&E  funds  into  the  program  and 
inserting  additional  DT&E  and  OT&E  phases  prior  to  the  next  year's 
production  decision  point.  Detailed  initial  attention  to  program  struc¬ 
ture  and  adequate  RDT&E  funding  should  ensure  that  no  more  than  one 
year's  production  is  carried  out  under  ALP  status. 


Advanced  Preparation  for  the  Production  Phase 


In  addition  to  the  normal  review  and  checks,  some  area  may  require 
special  attention  to  ensure  a  smooth  transition  to  production  and  de¬ 
ployment.  The  PM  should  review  the  system's  production  plan,  concentra¬ 
ting  on  those  portions  appropriate  to  the  Production  and  Deployment 
Phase  (see  DODD  5000.34).  He  should  give  special  attention  to  areas  of 
production  risk,  establish  requirements  for  parts  control,  initiate  long 
lead-time  procurements,  carefully  review  the  production  documentation 
package,  and  initiate  such  other  actions  as  may  be  necessary  to  facili¬ 
tate  transition  to  initial  volume  production  for  service  use. 

The  PM  should  also  review  the  manpower  requirements  for  operation 
and  maintenance  of  the  system,  and  any  changes  in  the  estimates  of  the 
number  and  level  of  training  should  be  discussed  during  the  Milestone 
III  review.  During  the  milestone  review,  the  PM  will  provide  a  summary 
(by  fiscal  year  and  occupational  specialty)  of  all  formal  training 
requirements  for  all  personnel  required  to  man  the  proposed  system,  and 
identify  numbers  of  personnel  trained  and  training  cost  (including  the 
cost  of  facility  modifications).  He  should  separately  identify  the  net 
impact  on  special -emphasis  training  program  such  as  undergraduate  flight 
training. 

During  the  milestone  review,  the  PM  should  summarize  plans  for  at¬ 
taining  and  maintaining  the  required  proficiency  of  operating  and  sup¬ 
port  personnel,  and  quantifying  the  scope  and  duration  of  their  on-the- 
job,  simulator,  and  formal  training  requirements.  He  should  identify 
anticipated  savings  from  the  use  of  simulator  or  other  training  device. 

Finally,  the  PM  should  review  the  facilities  that  the  Navy  will  use 
to  support  the  system  and  verify  that  any  new  facilities  required  by 
government  or  industry  are  adequate  and  will  be  available  when  needed. 


Planning  for  the  Production  and  Deployment  Phase 


In  preparation  for  Milestone  III  and  the  Production  and  Deployment 


Phase,  the  PM  should  ensure  that  all  the  documentation  required  for  the 
review  is  complete  and  the  program  is  ready  for  this  review.  The  list 
below  contains  major  requirements  for  the  Milestone  III  decision  to 
enter  into  full-scale  production  and  deployment. 

1.  The  mission  need  is  reaffirmed  in  the  light  of  an  updated 
threat. 

2.  Development  has  progressed  satisfactorily  and  the  DT&E/OT&E 
results  support  a  decision  to  proceed  with  production  and  deployment. 

3.  The  acquisition  strategy  has  been  updated  and  is  being  execut¬ 
ed. 

4.  Business  planning  supports  the  acquisition  strategy  and  pro¬ 
vides  flexibility  for  production  rates  and  quantities  when  options  are 
used. 


5.  Schedule  and  cost  estimates  remain  realistic  and  acceptable, 
including  support  and  operating  costs. 

6.  Design-to-cost  requirements  and  LCC  estimates  are  still  real¬ 
istic  and  will  permit  achievement  of  LCC  objectives. 

7.  The  system  continues  to  be  cost-effective  and  affordable  and 
remains  the  best  alternative  to  meet  the  mission  need. 

8.  Trade-offs  have  been  made  to  effectively  balance  cost,  sche¬ 
dule,  performance,  and  logistic  supportability  requirements. 

9.  Program  and  fiscal  year  funding  thresholds  are  reaffirmed. 

10.  Production  quantity  requirements  are  valid.  What  would  be  the 
impact  on  unit  cost  if  actually  budgeted  dollars  were  cut  below  the 
optimum  production  rates?  How  closely  tied  to  operational  requirements 
are  the  proposed  "optimum  rates"?  What  alternative  production  schedules 
are  reasonable  and  what  costs  are  involved  for  facilities,  and  special 
equipment  capitalization? 

11.  The  possibility  of  multi-year  procurement  and  its  effect  on 
cost  has  been  considered. 

12.  Issues  concerning  producibility,  reliability,  configuration 
control,  quality  assurance,  and  facilities  are  identified  and  satisfac¬ 
torily  provided  for. 

13.  The  program  management  structure  and  plan  for  the  full-scale 
Production  and  Deployment  Phase  are  sound  and  adequately  supported. 

14.  Major  problems  yet  to  be  solved  are  identified  and  a  satisfac¬ 
tory  plan  for  their  solution  exists. 

15.  NATO  standardization  and  interoperability  requirements  have 
been  satisfied. 
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16.  Required  future  production  decisions  have  been  identified  and 
incorporated  into  the  acquisition  strategy  and  functional  implementation 
plan. 


17.  Planning  for  deployment  has  been  completed  and  is  adequate, 
including  manpower  and  training,  logistic  readiness,  and  operational 
considerations  (including  integration  with  existing  operational  sys¬ 
tems). 

18.  The  adequacy  of  the  support  subsystems  being  provided  to  meet 
the  needs  of  initial  operational  units  has  been  assessed,  and  plans  have 
been  prepared  to  meet  any  reported  deficiencies. 

19.  The  production  readiness  review  has  been  completed  and  has 
determined  that  the  contractor  has  adequate  capability  to  manufacture 
the  system  and  is  prepared  to  commit  the  resources  necessary  to  achieve 
the  production  rate  required,  to  accomplish  rework,  and  to  furnish 
spares  as  necessary. 


MILESTONE  III 

Milestone  III  Review  Documentation  (MRP) 


The  MRD  required  at  Milestone  Ill  is  the  same  as  for  Milestone  II 
as  described  earlier. 


Milestone  III  Review  and  Approval 

The  review  and  approval  process  at  Milestone  III  is  the  same  as 
described  earlier  and  in  Appendix  A.  Normally  the  Milestone  III  deci¬ 
sion  for  ACAT  I  programs  is  delegated  by  the  SECDEF  to  the  SECNAV,  if 
the  thresholds  established  and  approved  at  Milestone  II  are  not  breach¬ 
ed.  If  thresholds  and  acquisition  plans  approved  at  Milestone  II  are 
not  breached,  no  further  OSD  review  is  necessary  for  ACAT  I  programs. 
The  approval  level  required  for  a  less-than-major  program  may  similarly 
be  delegated  downward. 


PRODUCTION  AND  DEPLOYMENT  PHASE 

Production  and  Deployment  Phase  efforts  will  be  directed  toward 
providing  and  maintaining  the  desired  operational  capability  and  inven¬ 
tory.  Production  of  hardware,  system  deployment,  and  the  establishment 
of  Fleet  support  operations  will  be  accomplished  through  the  plans 
already  prepared  by  the  program  team  and  approved  by  higher  authority. 
Figure  3-11  is  an  overview  of  the  inputs,  outputs,  and  principal  activi¬ 
ties  of  the  Production  and  Deployment  Phase. 


Transition  to  Full -Rate  Production 


At  the  commencement  of  the  Production  and  Deployment  Phase,  the  PM 
should  carefully  review  the  SDDM/SNDM/SPRDD/DADM  for  any  required  modi- 
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FIGURE  3-11.  Inputs,  Activities,  Outputs  of  Production  and  Deployment. 
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fications,  redirection,  or  restructuring  of  the  program.  Low-rate  pro¬ 
duction  may  already  have  been  initiated  under  a  limited  production 
decision,  Milestone  1 1 1 A,  prior  to  approval  for  full  production  and  the 
rendering  of  a  Milestone  III  decision.  If  not,  the  PM  should  proceed 
with  procurement  from  the  developing  contractor,  whose  production  capa¬ 
bility  will  already  have  been  established  in  the  pilot-production  pro¬ 
gram.  The  procurement  schedule  and  the  budget  must  be  carefully  coor¬ 
dinated  to  avoid  long  gaps  between  Milestone  III  and  IOC. 

Low-Rate  Production  Schedule.  Initial  low-rate  production  can 
provi3e  the  additional  units  as  well  as  the  time  needed  to  confirm  the 
adequacy  of  the  product  baseline  and  to  qualify  any  design  or  production 
process  changes  that  may  be  required  (or  that  may  have  been  deferred) 
before  proceeding  to  high-rate  production. 

Low-rate  production  schedules  are  uneconomical  and  should  be  of 
short  duration  unless  they  are  required  by  the  budget  or  other  obliga¬ 
tion.  To  establish  an  acceptable  low-rate  production  schedule,  stepped 
increases  in  production  rate  quantities  should  be  optimized  in  regard  to 
the  contractor's  production  costs,  government  in-house  costs,  and  weapon 
system  life-cycle  costs.  The  most  economical  and/or  "best  schedule" 
should  be  arrived  at  through  intensive  cost  analysis  and  trade-offs 
involving  both  budgetary  and  programmatic  considerations. 

Unacceptable  low-rate  production  schedules  result  in  excessive  unit 
cost  (both  fixed  and  variable),  and  intermittent  subcontractor/ vendor 
procurements.  The  unacceptability  of  low-rate  production  schedules  can 
only  be  determined  after  considering  the  cost  to  buy-out  a  specified 
quantity  versus  the  cost  to  sustain  a  low-rate  production  including 
mobilization  requirements. 

Optimum  Full-Rate  Production/Economical  Production  Rate.  Full-rate 
production  provides  the  best  means  of  amortizing  fixed  costs  and  achiev¬ 
ing  the  lowest  unit  manufacturing  cost.  Full-rate  production  should 
commence  as  soon  as  the  product  baseline  has  stabilized  and  the  contrac¬ 
tor's  capability  is  established. 

Before  committing  the  government  for  full-rate  production,  stepped 
increases  in  quantities  should  be  optimized  in  regard  to  contractor's 
production  costs,  in-house  costs,  and  LCC  including  shelf-life  and 
multiple-source  considerations.  Contractor's  production  costs  should 
address  the  constraints  of  tooling  and  test  equipment  rate  capability, 
multiple  shifts,  and  dedicated  facilities  (brick  and  mortar).  In-house 
costs  should  address  the  impact  on  government  production  and  storage 
facilities  as  well  as  administrative  burden.  Also,  care  must  be  exer¬ 
cised  to  avoid  lost  economic  opportunity  by  over/under  production  of 
separately  procured  items.  As  with  low-rate  production  schedules,  the 
most  economical  and/or  "best  schedule"  should  be  arrived  at  through 
intensive  cost  analysis  and  trade-offs  involving  both  budgetary  and 
programmatic  considerations. 

Unacceptable  variations  from  the  most  economical  production  rate 
will  result  in  higher  overall  cost,  cause  degradation  of  design  integri¬ 
ty  and/or  quality  of  the  end  product,  and  in  certain  instances,  outpace 


the  availability  of  other  components  of  the  system  and  thereby  incur 
lost  economic  opportunity. 

Maintaining  Competition  through  Multiple  Sources.  Minimum  quanti¬ 
ties  that  can ' support  multiple-source  (second  source)  competition  should 
be  determined  early  and,  where  cost  analysis  indicate  that  total  pro¬ 
curement  cost  can  be  reduced,  provisions  for  a  second-source  program 
should  be  incorporated  into  the  acquisition  strategy.  In  addition  to 
cost  reduction,  a  better-defined  and  higher-quality  product  usually 
emerges.  An  increase  of  production  capacity  and  surge  capability  is 
created  and  lower  vulnerability  to  disasters  due  to  dispersed  production 
is  obtained.  Second-  or  alternative-source  qualification  should  begin 
immediately,  if  it  has  not  already  been  done,  by  contracting  with  com¬ 
petitively  selected  sources  for  a  small  number  of  systems  or  subsystems. 
Qualification  tests  of  these  systems  will  determine  the  new  sources' 
compatibility  with  the  documentation  package.  Once  qualified,  the  new 
sources  become  eligible  to  participate  in  competition  for  subsequent 
buys  on  an  equal  footing  with  the  development/pilot-production  contrac¬ 
tor. 


Maintaining  Rate  Production  of  a  Quality  Product 

In  order  to  obtain  and  maintain  rate  production  of  a  quality  pro¬ 
duct  for  fleet  use,  it  is  imperative  that  the  PM  exercise  stringent 
oversight  of  a  number  of  critical  areas.  These  include:  configuration 
control,  quality  control  (QC) /quality  assurance  (QA),  control  cf  noncon¬ 
forming  material,  and  recurrent  problem/failure  control .  While  the 
general  aspects  of  these  topics  are  discussed  below,  they  are  covered  in 
more  detail  in  Section  4,  Critical  Topics. 


Most  PMs  are  required  to  spend  an  inordinate  amount  of  effort  on 
these  aspects  of  the  Production  and  Deployment  Phase.  For  each  of  these 
topics,  an  ounce  of  pre-planning  and  effort  is  worth  pounds,  dollars  and 
months  of  effort  in  attempting  cures. 


Configuration  Control.  Configuration  control  during  the  develop¬ 
ment  phases  was  "intended  to  facilitate  the  design  evolution  process. 
Its  practice  was  comparatively  loose.  By  contrast.  Production  and 
Deployment  Phase  configuration  control  must  be  practiced  rigorously. 
Changes  should  be  allowed  only  when  it  can  be  justified  by  cost-effec¬ 
tiveness  or  for  the  correction  of  problems  or  failure.  Even  then  the 
total  ''mpact  of  a  change  must  be  carefully  assessed  and  action  must  be 
taken  to  accommodate  all  ramifications  of  the  change.  MIL-STD  480 
controls  the  configuration  change  process  and  should  be  implemented  in 
all  production  contracts. 


Production  contractors  should  be  required  to  utilize  and  provide 
the  program  management  office  with  Level  3  (MIL-D-1 OOOA )  engineering 
drawings  and  associated  lists  as  a  means  of  tightening  configuration 
control  and  enhancing  product  maturation.  The  dpsign  of  systems  or 
comoonents  bought  at  a  lower-level  document  package  has  not  matured  or 
gone  through  as  stringent  a  government  design  review.  Level  3  documen¬ 
tation  review  adds  to  the  Navy  corporate  memory  and  facilitates  second- 
source  competition. 
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Maintenance  of  the  package  is  especially  critical  to  configuration 
control.  The  PM  must  ensure  that  the  product  baseline  configuration 
reflects  the  current  design  at  all  times  and  that  details  of  the  changed 
configuration  are  routinely  made  available  to  activities  who  need  infor¬ 
mation,  such  as  contractors  and  maintenance  personnel.  Extra  care  is 
required  when  the  product  baseline  configuration  involves  both  (1)  a 
function  or  performance  specification  and  (2)  a  fabrication  or  design 
specification,  in  the  form  of  product  drawings,  manufacturing  processes 
and  procedures,  and  in-process  and  acceptance  test  and  inspection  re¬ 
quirements.  Many  of  the  high-volume  production  weapons  procured  by  the 
Navy  fall  in  this  category.  When  the  acquisition  strategy  calls  for 
competitive  re- procurement  to  a  rigorously  controlled,  government-owned 
and  maintained  data  package,  the  program  manager  is  advised  to  call  upon 
one  of  the  Navy  laboratories  or  centers  to  assume  responsibility  for 
maintenance  of  the  re-procurement  data  package.  A  laboratory  or  center 
that  participated  in  the  development  phases  is  a  natural  candidate  for 
this  service. 

Quality  Control  (QC)  and  Quality  Assurance  (QA).  Primary  responsi¬ 
bility  for  accomplishment  of  QC  rests  with  the  contractor;  primary 
responsibility  for  assuring  that  the  contractor's  QC  program  is  being 
properly  implemented  rests  with  the  local  DCAS  or  resident  plant  repre¬ 
sentative  office  (PRO);  and  responsibility  for  conduct  of  the  PAT&E 
portion  of  the  OA  program  rests  with  the  representatives  of  the  project 
contracting  officer  at  the  designated  quality-assurance  test  activities. 

The  PM  should  enlist  the  service  of  a  knowledgeable  government 
activity  such  as  a  Navy  laboratory  to  render  assistance  in: 

1.  Reviewing,  approving,  and  monitoring  contractor  QC  plans  in¬ 
cluding  implementation  of  the  manufacturing  screening  fundamentals  of 
NAVMAT  P-9492. 

2.  Structuring  and  conducting  government-sponsored  QA  programs. 

3.  Auditing  contractor.  Defense  Contract  Administration  Service 
(DCAS),  and  test  activity  implementation  of  approved  contractor  QC  and 
government  QA  programs. 

While  the  emphasis  placed  here  on  QC/QA  might  seem  to  be  an  over¬ 
kill,  the  importance  of  ensuring  the  delivery  of  a  high-quality  product 
with  minimum  latent  defects  into  the  service  inventory  is  ample  justifi¬ 
cation.  Delivery  of  inferior  products  not  only  lays  the  groundwork  for 
expensive  and  time-consuming  inventory  purging  and  rework  programs,  but 
robs  the  using  commanders  of  their  operations1  capability. 

Nonconforming  Material.  The  major  cause  of  nonconforming  material 
is  the  failure  of  the  contractor  to  control  his  assembly  procedures  and 
material  procurement.  Improper  material  procurement  by  the  contractor 
may  include  the  failure  to  properly  transmit  contract  documentation  from 
contractor  to  subcontractor,  and  inadequate  inspection  procedures. 

The  PM  should  see  that  contracts  contain  a  clause  pertaining  to 
"Configuration  control;  engineering  changes,  deviations  and  waivers". 
This  is  permitted  by  MIL-STD  480.  This  clause  establishes  a  Material 
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Review  Board  (MRB),  with  the  Government  having  final  authority  over  all 
board  decisions.  The  options  for  disposal  of  nonconforming  material  are 
use  as  is,  scrap,  repair,  or  rework. 

The  Government  representative  on  the  MRB  is  typically  the  DCAS/PRO. 
He  is  empowered  to  make  decisions  on  the  acceptance  or  rejection  only  of 
those  waivers  that  do  not  affect  form,  fit,  function,  or  safety.  The 
DCAS/PRO  may  require  technical  assistance  from  the  program  management 
office  or  a  supporting  field  activity  to  evaluate  the  impact  of  the 
nonconforming  material  on  system  reliability,  performance,  and  safety, 
as  well  as  the  acceptability  of  corrective  actions.  Provisions  should 
be  made  for  ready  access  of  the  DCAS/PRO  to  such  assistance. 

Recurrent  Problem/Failure  Control.  The  identification  and  correc¬ 
tion  of  problems  and  failures  is  critical  to  the  production  program. 
The  contractor  must  be  required  to  set  up  a  closed-loop  system  that 
isolates  and  identifies  problems  and  ensures  that  corrective  action  is 
taken.  The  problem-failure-recurrence  control  system  should  encompass: 

1.  Reporting  problem/failure  conditions 

2.  Collecting  and  classifying  data  and  determining  trends 

3.  Analyzing  data  and  establishing  probable  cause 

4.  Taking  corrective  action 

a.  Recommended  actions  to  preclude  recurrence 

b.  Effective  schedule 

5.  Verifying  that  corrective  action  is  taken 

6.  Follow-up;  i.e.,  how  effective  was  action 

The  control  system  should  not  treat  the  problems  and  failures 
merely  as  random  incidents,  but  should  be  designed  to  locate  and  elim¬ 
inate  the  causes  of  each.  Typical  failure  causes  and  appropriate  action 
are  illustrated  in  Figure  3-12. 

Maintaining  Competition  through  Component  Breakout.  Some  systems 
will  “be  of  such  low  production  volume  or  require  such  specialized  pro¬ 
duction  facilities  that  competitive  re-procurement,  of  the  entire  system 
will  net  be  appropriate.  However,  there  will  usually  be  subsystems  and 
components  that  can  be  broken  out  and  procured  competitively.  Such 
competition  in  the  procurement  of  subsystems  and  components  should  lead 
to  lower  procurement  costs  and,  possibly,  to  improved  characteristics. 
Component  breakout  will  facilitate  meeting  small -business  objectives  as 
well  as  achieve  additional  cost  savings  by  eliminating  the  prime  con¬ 
tractor's  middleman  role. 

These  desirable  features  are  not  obtained  without  some  drawbacks. 
Component  breakout  becomes  increasingly  risky  with  the  heightened  com¬ 
plexity  of  modern  weapon  systems  and  the  reductions  in  personnel  avail¬ 
able  to  manage  GFE.  Frequently  the  prime  contractor  actively  opposes 
component  breakout.  Reasons  for  this  include:  the  prime  contractor  may 
feel  that  his  expertise  and  management  ability  can  effectively  be  used 
in  selecting  the  component  manufacturers  and  ensuring  that  their  pro¬ 
ducts  meet  his  exacting  standards  (some  contractor's  standards  are 
indeed  higher  than  the  government's)  in  order  to  ensure  overall  system 
reliability  and  performance.  Late-supplied  or  defective  government- 
furnished  equipment  can  also  have  an  adverse  effect  on  the  contractor's 
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internal  operations  as  well  as  his  reputation. 


FAILURE  CAUSES 

CORRECTIVE  ACTION 

DESIGN  INADEQUACY 

INCORPORATE  SUITABLE  DESIGN  CHANGES 

defective  PARTS 

IMPROVE  VENDOR  CONTROL 

INCREASE  INCOMING  INSPECTION 

IMPLEMENT  PARTS  RESCREENING 

TEST  ERRORS 

MODIFY  TEST  PROCEDURES/EQUIPMENT 

IMPROVE  TRAINING  FOR  TEST  TECHNICIANS 

ASSEMBLY  ERRORS 

CLARIFY  ASSEM8LY  INSTRUCTIONS 

INCREASE  INSPECTION  POINTS 

IMPROVE  TRAINING  FOR  OPERATORS/INSPECTORS 
IMPLEMENT  NAMAT-P-9492 

PROCESS  PROBLEMS 

TIGHTEN  PROCESS  CONTROLS 

MODIFY  THE  PROCESS 

USE  ALTERNATIVE  PROCESS 

IMPLEMENT  NAVMAT-P-9492 

MISHANDLING 

USE  ADEQUATE  HANDLING  EQUIPMENT 
INCORPORATE  SUITABLE  PACKAGING 

IMPROVE  training  for  PERSONNEL 

MINIMIZE  HANDLING 

FIGURE  3-12.  Typical  Failure  Causes  and  Corrective  Actions. 


There  is  also  a  financial  motive  in  resisting  close  government 
control  of  component  breakout.  Most  contractors  allow  (and  many  prime 
contractors  have  adopted)  accounting  systems  in  which  a  profit  factor  is 
applied  to  the  prices  paid  for  subcontracted  components  as  well  as  for 
administrative  and  engineering  fees  necessary  to  adapt  and  ensure  fit  of 
the  components.  Such  accounting  devices  have  been  used  even  in  cases 
where  a  government  agency  was  the  "subcontractor"  for  the  items  such  as 
warheads  and  fuzes. 


Deployment  and  Fleet  Support 

Planning  for  the  smooth  phase-in  of  a  new  system  and  phase-out  of 
the  old  must  be  undertaken  several  years  prior  to  actual  commencement  of 
the  task.  Although  the  mechanics  of  deployment  are  very  equipment- 
specific,  the  need  for  careful  planning  cannot  be  overstated,  particu¬ 
larly  in  regard  to  the  training  of  needed  personnel  and  the  establish¬ 
ment  and  placement  of  system  support.  Fleet  support  from  contractor  or 
Navy  laboratory  personnel  on  first  deployments  is  in  most  cases  desir¬ 
able  and  in  certain  cases  necessary.  These  technical  personnel  serve 
the  dual  purpose  of  ensuring  proper  initial  installation,  servicing,  and 
use,  and  of  speeding  up  feedback  from  the  user  to  the  design  agent. 

Fleet  support  can  be  broken  down  into  phase-in  support,  operations 
support,  and  phase-out  support.  The  phase-in  support  period  start  with 
the  IOC  date  and  ends  whenever  the  full  operational  support  is  initiat¬ 
ed,  Phase-in  support  is  normally  procured  at  the  same  time  as  the 
equipment  and  most  often  will  consist  of  contractor-supplied  training 
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and  initial  spare  parts.  Warranty  service  and  maintenance  contracts 
also  fall  into  this  support  category.  The  planning  for  phase-in  support 
must  be  accomplished  during  the  latter  stage  of  the  F$D  Phase  program. 

Operational  support  is  required  throughout  the  service  life  of  the 
system.  There  is  a  continuing  need  for  a  responsible  agency  for  in- 
service  engineering  throughout  the  life-cycle  of  any  system  to  represent 
the  interests  of  the  end  user  of  the  system  and  to  direct  contractor 
activity  in  repair,  refurbishment  and  update/improvement  of  the  system 
in  question.  Operational  support  requirements  are  initially  predicted 
by  the  ILS  tasks  performed  during  the  earlier  phases.  They  are  con¬ 
stantly  corrected  by  the  various  support  management  effectiveness  sys¬ 
tems  utilized  by  the  supply  system,  training  commands,  operational 
commands,  systems  commands,  field  support  activities,  etc. 

The  support  system  is  set  up  for  long-term,  continuous  operations. 
It  is,  therefore,  extremely  important  to  properly  plan  the  transitional 
support  for  a  system.  The  planning  requires  not  only  the  accurate 
.execution  of  the  ILS  tasks  but  also  ensuring  that  the  funds  and  other 
resources  are  available  to  implement  the  approved  ILS  plans.  Identify¬ 
ing  funds  requires  budgeting  actions  that  will  take  at  least  2  years  to 
produce  the  allocation.  Identifying  personnel  resources  may  require 
changing  manpower  allocations  and  recruiting  quotas,  setting  up  training 
courses,  scheduling  a  training  pipeline,  and  it  may  take  3  or  more  years 
before  the  personnel  are  available.  Since  these  are  long  lead-time 
actions  that  may  exceed  the  time  needed  to  procure  the  equipment,  the 
phase-in  support  planning  becomes  very  important. 

All  too  often  the  planning  for  operational  support  is  incomplete, 
especially  in  the  identification  of  funding  for  training  and  spare 
parts.  When  the  new  system  is  put  into  the  Fleet  without  proper  plan¬ 
ning  or  initial  support,  the  unsupported  equipment  suffers  abuses  that 
often  permanently  degrade  performance  and  reliability.  Low  system  a- 
vai lability  may  cheat  the  user  of  a  needed  capability  and  cause  the 
expenditure  of  manpower  and  dollar  resources  better  spent  elsewhere. 

A  frequently  overlooked  support  requirement  is  the  technical  data 
needed  to  set  up  and  utilize  the  available  support  management  effective¬ 
ness  systems.  The  most  important  of  these  systems  is  the  maintenance 
data  collection  system  (MDCS )  portion  of  the  maintenance  and  material 
management  system.  MDCS  takes  maintenance  reports  from  the  Fleet  and 
computes  logistic  and  reliability,  maintainability,  and  availability 
(RM&A)  parameters.  The  logistics  parameters  are  straightforward  calcu¬ 
lations  of  usage  and  parts-demand  data  and  are  used  to  isolate  and 
correct  supply  system  deficiencies.  The  RM&A  parameters  are  used  to 
identify  latent  design,  support  documentation,  training,  installation, 
and  manning  problems,  and  insufficient  test  equipment  allocations. 


PRODUCT  IMPROVEMENT 

Rarely  will  the  first  production  designs  of  a  new  system  prove 
fully  satisfactory.  Changes  in  the  threat,  tactics,  interacting  sys¬ 
tems,  or  new  technical  achievements  may  have  occurred  too  late  during 
the  system  development  to  be  incorporated  in  the  design.  Deficiencies 
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may  show  up  during  Fleet  use  that  were  not  uncovered  during  development 
or  OPEVAL,  or  the  development  program  may  have  been  carried  out  on  the 
assumption  that  a  P3I  program  would  be  implemented  to  compensate  for  an 
early  Fleet  introduction  of  the  basic  system  capability.  Since  it  is 
rarely  possible  to  field  an  optimized  design  on  the  first  try,  it  is 
necessary  to  implement  a  vigorous  product  improvement  plan  (PIP)  to 
include  all  the  improvements  that  the  ongoing  development  and  production 
program  could  not  incorporate  on  the  first  pass. 

As  a  first  step  in  developing  the  PIP,  the  PM  and  his  staff  should 
review  their  objectives  in  light  of  the  compromises,  design  shortfalls, 
and  discoveries  made  during  the  course  of  development  and  early  produc¬ 
tion,  and  identify  the  subsystems,  processes,  and  parts  that  could  or 
should  be  improved.  The  PIP  should  provide  a  framework  for  identifying 
areas  in  which  changes  will  be  beneficial,  and  for  implementing  product 
modifications  and  procedural  changes  that  will  improve  performance, 
producibility,  reliability,  safety,  will  decrease  costs,  will  have  any 
other  beneficial  results. 

The  PIP  is  conducted  in  much  the  same  manner  as  the  initial  system 
development:  investigation  of  need,  review  of  alternatives,  demonstra¬ 
tion  and  validation  of  the  changes,  product  engineering,  follow-on  test 
and  evaluation,  and  possible  re-release  of  the  finished  product  with  a 
new  approval  for  full  production.  Documentation  and  configuration  con¬ 
trol  are  important.  PIP  modifications  should  not  be  introduced  on  a 
piecemeal  basis  and  the  necessary  changes  in  the  ILS,  manpower,  person¬ 
nel  and  training  systems  (MP&TS),  and  other  affected  areas  need  to  be 
coordinated.  Provision  must  be  made  for  the  orderly  expenditure  of 
inventory  and  return  of  deployed  units  for  modification.  The  supply 
system  and  the  Fleet  must  know  the  state  of  the  PIP  at  all  times, 
particularly  if  significant  changes  in  operational  effectiveness  have 
resulted.  Support,  training  programs,  and  changes  in  recommended  tac¬ 
tics  must  precede  the  deployment  of  the  modified  system. 


PROGRAM  MANAGEMENT  OFFICE  (PMO)  PHASE-OUT 

The  program  phase-out  plans  provide  for  the  transition  of  continu¬ 
ing  system  tasks  into  functional  organizations  and  for  documenting  the 
program  history.  The  phase-out  plan  should  incorporate  a  WBS  and  should 
show  the  completion  dates  and  the  person  or  organization  responsible. 
Continuing  or  recurring  tasks  should  show  who  were  responsible  in  the 
program  organization  and  the  persons  or  organizations  assuming  the 
responsibility.  The  coordinating  plans  or  documents  and  any  other 
pertinent  data  should  be  referenced,  and  storage  points  and  holders 
should  be  cited.  Common  documents  would  include,  as  a  minimum,  the 
ILSP,  training  plans,  configuration  baseline  and  data,  and  re-procure¬ 
ment  data.  The  historical  section  should  include  a  listing  of  all 
permanent  program  documents,  reports,  and  data.  These  items  should 
cover  the  design  and  development,  testing,  acquisition,  ILS,  installa¬ 
tion,  initial  field  data,  quality  and  workmanship,  and  actual  costs  and 
schedules  compared  to  the  planned  targets.  Any  significant  achievements 
of  the  program,  significant  problems,  and  any  lessons  learned  should  be 
incorporated  in  a  narrative.  Any  innovations  or  patents  should  be 
mentioned.  The  program's  successes  and  failures  provide  valuable  les- 


sons  for  the  many  similar  programs  that  will  follow,  and  can  also  point 
to  areas  in  which  organizational  policies  should  be  improved. 


SYSTEM  PHASE-OUT 

The  most  overlooked  support  phase  is  phase-out.  Usually,  a  system 
is  phased  out  because  a  replacement  system  is  being  phased  in.  As  a 
system  nears  the  end  of  its  service  life,  various  support  elements 
become  uneconomical  and  are  dropped.  Special  training  courses  are 
ended,  maintenance  contracts  are  terminated,  etc.  In  today's  austere 
budget  environment,  the  acquisition  program  for  the  replacement  equip¬ 
ment  can  hardly  be  expected  to  assist  a  "lame  duck"  system.  Most  of  the 
problems  that  can  occur  during  phase-out  can  only  be  addressed  early  in 
the  acquisition  cycle  of  the  particular  system  being  phased  out.  Levels 
of  repair  and  standardization  should  be  established  such  that  system- 
peculiar  items  are  minimal  and  are  not  system-critical,  and  minimal 
skills  are  required  to  operate  and  maintain  the  system.  A  maintenance 
contract  might  be  structured  on  a  cost-per-unit  basis.  Consideration  of 
the  phase-out  problems  that  may  occur  for  a  system  being  replaced  by  the 
current  acquisition  may  make  it  desirable  to  alter  the  phase-in  rate  and 
hence  the  production  rate  of  the  new  equipment. 
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CRITICAL  TOPICS 


THE  MANAGEMENT  PROCESS 


"The  most  involved  fact  in  the  world  could  have  been 
faced  when  it  was  simple,  the  biggest  problem  in 
the  world  could  have  been  solved  when  in  was  small." 

Lao-tzu  (circa  550  B.C.) 


The  function  of  a  ranager  is  to  identify  problems  while  they  are 
small,  before  any  of  the  options  that  may  exist  for  their  solutions 
become  unavailable,  and  to  make  the  decision  necessary  to  solve  those 
problems.  In  practice,  of  course,  the  accomplishment  of  these  two 
"simple"  functions  is  much  more  complex.  Any  approach  to  the  management 
process  can  be  shown  to  consist  of  six  iterative,  sometimes  commingled, 
steps.  These  are: 

1.  Establishment  of  an  acquisition  strategy 

2.  Establishment  of  a  baseline  plan 

3.  Measurement  of  progress 

4.  Comparison  of  actual  progress  to  the  baseline 

5.  Analysis  of  any  variances  between  actual  and  planned  progress 

6.  Making  corrections 


Establishment  of  an  Acquisition  Strategy 

SECNAVINST  5000.1  states  "Acquisition  Strategy.  From  program  start 
an  overall  plan  to  acquire,  produce  and  support  the  system  shall  be 
developed  and  tailored  to  the  unique  circumstances  of  the  program.  It 
shall  set  forth  the  objectives,  resources,  principal  assumptions,  and 
contracting  approach,  including  extent  of  competition.  ...The  acquisi¬ 
tion  strategy  shall  be  executed  with  maximum  tailoring,  flexibility, 
innovation  and  common  sense." 

OPNAVINST  5000.42  states  "Acquisition  Strategy  defined  in  broad 
terms  ...  includes  not  only  elements  such  as  contract  type,  competition, 
industrial  base,  etc.  ...  but  also  such  elements  as  program  structure, 
requirements,  thresholds,  priorities,  resources,  QT&E,  etc.  ...  The 
foundation  of  acquisition  strategy  lies  in  these  latter  elements  - 
particularly  program  structure  ..." 


Acquisition  Strategy  Development  During  the  Concept  E;:pl oration 
Phase.  The  acquisition  strategy  forms  the  basis  For  the  development  of 
other  program  documentation  (System  Concept  Paper  (SCP),  Decision  Coor¬ 
dinating  Paper  (DCP),  Integrated  Program  Summary  (IPS),  Navy  Decision 
Coordinating  Paper  (NDCP),  Test  and  Evaluation  Master  Plan  (TEMP),  etc.) 
and  serves  as  a  means  for  correlating  individual  program  decisions  with 
the  Planning,  Programming  and  Budgeting  System  (PPBS),  Details  of  the 


policies,  procedures,  format,  and  content  for  the  acquisition  strategy 
document  are  given  in  NAVMATINST  5000.29  ("Acquisition  Strategy")  and 
are  available  from  MAT-021. 

Selecting  an  acquisition  strategy  for  a  weapon  system  is  one  of  the 
most  important  decisions  in  making  the  fielding  of  that  system  a  reali¬ 
ty.  The  acquisition  strategy  decision  has  far-ranging  impacts  on  the 
possibilities  of  generating  competitive  cost  savings  and  on  the  degree 
of  success  in  meeting  performance  and  schedule  parameters.  Since  the 
decision  and  its  outcomes  are  not  obvious,  the  decision  should  be  made 
only  after  careful  considerations  of  available  options.  The  potential 
strategies  should  be  analyzed  as  to  the  various  objectives  they  would 
affect  or  achieve  and  as  to  appropriateness  for  the  special  conditions 
of  the  specific  system. 

The  acquisition  strategy  must  serve  as  a  responsive  and  flexible 
instrument  for  ensuring  that  adaptive  approaches  to  the  acquisition  pro¬ 
cess  are  pursued.  Emphasis  is  on  near  term,  but  the  strategy  will  be 
constantly  under  development  and  will  be  updated  periodically  during  the 
life  of  the  program.  As  a  practical  matter  within  the  PMO,  the  business 
manager  is  the  focal  point  for  the  acquisition  strategy.  It  is  prepared 
by  the  business  manager  and  PM  with  the  assistance  of  the  Command  Deputy 
for  Acquisition  and  Contracts  and  other  functional  specialists. 

The  acquisition  strategy  is  submitted  through  the  chain  of  command 
to  the  Chief  of  Naval  Material  (CNM)  for  approval.  Once  approved,  the 
acquisition  strategy  becomes  the  contract  between  the  PM  and  CNM  rela¬ 
tive  to  the  acquisition  procedures  that  will  be  followed.  It  also 
serves  as  a  communication  mechanism  between  CNM  and  higher  authority 
concerning  the  acquisition  approach  being  used. 

NAVMATINST  5000.29  was  issued  to  allow  an  approved  acquisition  strategy 
plan  (ASP)  to  be  used  instead  of  a  Request  for  Authority  to  Negotiate 
(RAN)  in  support  of  a  Secretarial  Determination  and  Finding  (D&F)  if  the 
information  required  by  paragraph  3-306,52  of  the  Navy  Acquisition 
Requirements  was  included.  This  has  not  been  the  case.  Typically,  an 
acquisition  or  contracting  plan  which  xxxxxxxx  the  ASP  is  prepared  as 
well  as  the  RAN/D&F.  It  should  be  noted  that  the  Competition  in  Con¬ 
tracting  Act  of  1984  significantly  changes  this  methodology.  New  in¬ 
structions  are  in  the  process  of  being  prepared. 

Tailoring  the  Acquisition  Strategy.  The  acquisition  strategy  must 
be  tailored  to  the  particular  program's  needs.  Figure  4-1  outlines 
examples  of  tailored  acquisition  strategies. 

Since  each  program  has  different  requirements,  it  is  impossible  to 
detail  all  of  the  items  requiring  consideration  in  the  preparation  of 
every  acquisition  strategy.  However,  the  acquisition  strategy  submitted 
to  CNM  would  typically  address  the  following: 

1.  Management  concepts: 

a.  Use  of  organizational  assets  (Headquarters  personnel, 
government  laboratories,  industry,  universities,  and 
others) 
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FIGURE  4-1.  Examples  of  Tailored  Acquisition  Strategies. 


b.  Planning  and  control  of  critical  program  activities 

c.  Establishing  the  baseline  for  the  integrated  logistics 
support  plan  (ILSP)  and  the  TEMP 

d.  Identification  of  known-unknowns  and  their  likely  impact 

e.  Scheduling 

f.  Testing,  demonstration  and  evaluation.  What  overlap  of 
development  test  and  evaluation  ( DT&E )  and  OT&E?  What 
special  T8E  equipment  and/or  facilities  are  required? 

2.  Interdependence  of  effort  with  other  programs: 

a.  Platforms  on  which  the  developing  system  is  to  be  used 

b.  Other  programs  on  which  the  program  depends  for  technol¬ 
ogy  demonstrations,  fallback  options,  interface  require¬ 
ments,  or  components 

c.  Interservice  or  North  Atlantic  Treaty  Organization  (NATO) 
interoperability  requirements 

3.  Competition: 

a.  Methods  for  obtaining  and  maintaining  competition 

b.  Into  what  phases  should  competition  extend  and  at  what 
level  (system,  subsystem,  component)? 

c.  Will  there  be  competitive  procurement?  Re-procureme.t? 

d.  How  many  and  what  kind  of  competitors? 

e.  Cost/benefit  analysis 
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f.  How  and  when  to  transfer  laboratory  contributions/govern- 
ment-owned  information  to  competitors 

g.  Selection  criteria  for  choosing  best  alternatives 

h.  Funds  available,  timing 

4.  Contracting: 

a.  Type  of  contract  for  each  phase  and  rationale  for  its 
selection 

b.  Contracting  plan 

c.  Preparation  of  solicitation  for  proposals 

d.  Makeup  of  source  selection  and  proposal  evaluation  teams 

e.  Evaluation  of  proposals,  criteria 

f.  Use  and  handling  of  proprietary  materials;  how  to  obtain 
government  rights  to  them;  how  essential  is  government 
control  of  the  proprietary  material? 

g.  Contracting  initiatives,  use  of  contract  incentives 

h.  Monitoring  contracts  and  contract  controls 

5.  Design-to-cost  and  life-cycle  costs  (LCC): 

a.  Methods  for  projecting  LCC 

b.  Goals  for  design-to-cost,  when,  how  rigid 

c.  Manpower,  resources,  logistics,  energy 

d.  When  to  start  and  fund  product  improvement  programs 

6.  Budgeting  considerations 

a.  Realistic  funding  requirements  (by  phase)  to  achieve 
objectives,  including  land-based  test  support,  T&E,  and 
1LS 

b.  Estimates  of  cost  associated  with  cost  growth  during 
research  and  development 

c.  Effect  of  decreased  budget  allocations  on  production 
rate,  unit  cost,  program  "stretch-out",  minimal  and  opti¬ 
mal  amounts  required  yearly  for  each  phase 


Functional  Implementation  Plans  (FIPs).  To  supplement  the  approved 
acquisition  strategy  the  PM  must  prepare  and  regularly  update  a  series 
of  FIPs  such  as  those  shown  in  Figure  4-2  on  the  next  page. 

It  should  be  noted  that  Figure  4-2  addresses  only  those  FIPs  speci¬ 
fically  called  out  in  DODD  5000.1.  Other  FIPs  may  also  be  required  such 
as  those  that  cover  contracting,  LCC,  configuration  management,  data 
management,  maintenance  and  support,  reliability,  safety,  and  training. 
Other  FIPs  covering  matter  such  as  production  and  parts  control  may  be 
required  in  later  phases. 

The  FIPs  should  contain  all  major  tasks,  inputs,  outputs,  sche¬ 
dules,  and  sub-milestones,  as  well  as  manloading  and  the  dollar-per-time 
estimates.  Each  task  should  be  sufficiently  detailed  to  permit  accurate 
monthly  progress  measurement.  Tasks  should  be  updated  as  changes  occur, 
and  tasks  should  be  added  as  new  areas  are  identified  and  problems 
surface.  The  FIPs,  together  with  comprehensive  monthly  status  reports 


S 
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FIGURE  4-2.  Acquisition  Planning  Relationships. 


distributed  to  program  members,  can  serve  a  valuable  communication  role. 


Acquisition  Strategy  Update  During  the  D&V  Phase.  During  the  D&V 
Phased  the  acquisition  strategy  is  updated  to  ensure  that  it  follows  the 
guidance  received  from  higher  authority  during  the  Milestone  I  review 
process  and  with  NAVMATINST  5000.29.  The  acquisition  strategy  should  be 
broad-based  and  topically  parallel  to  the  Integrated  Program  Summary 
(IPS).  It  should  contain  the  following: 

1.  A  plan  for  defining  the  evaluation  criteria  for  the  demonstra¬ 
tion  and  validation  contracts. 

2.  A  plan  to  ensure  that  complete  specifications  of  compatibility 
requirements  for  interface  between  candidate  concepts  and 
related  systems  and  equipment  are  promulgated  to  the  competing 
contractors. 

3.  A  plan  for  maximizing  competition 

4.  A  financial  strategy  with  realistic  maximum-minimum  funding 
requirements 
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5.  A  plan  for  the  use  of  Navy  activities  to  assist  in: 

a.  Developing  government-furnished  equipment  (GFE)  subsys¬ 
tems,  e.g.,  warheads,  fuses 

b.  Defining  the  evaluation  criteria 

c.  Preparing  the  work  statements  and  data  requirements  for 
the  RFP 

d.  Providing  technical  information  to  the  contractor 

e.  Evaluating  contractor  submissions 

f.  Defining  the  support  and  facilities  needed  for  the  next 
phase 

g.  Conducting  in-process  reviews  of  documentation 

6.  T&E  requirements  and  criteria  that  reflect  the  particular 
needs  of  the  demonstration  and  validation  effort. 

7.  A  plan  for  independently  estimating  LCC  in  sufficient  detail 
for  meaningful  concept  comparison. 

8.  A  list  of  critical  performance  and  technological  advances  that 
must  be  achieved  in  order  to  meet  program  goals. 

9.  A  discussion  of  the  specific  approaches  that  the  program 
manager  will  use  in  dealing  with: 

a.  Untested  technologies  and  other  technical /cost/schedule 
risk  factors 

b.  Hardware  test  data  required  to  substantiate  prediction 

c.  Material  and  components  not  currently  being  manufactured 
under  established  process  control 

d.  "People  functions"  required  for  system  operation  and 
their  compatibility  with  use  conditions 

e.  Alternative  or  secondary  functions  of  the  system  and 
their  impact  on  the  primary  mission 

f.  Susceptibility  of  the  system  to  the  anticipated  RF  envi¬ 
ronment,  hostile  weapon  systems,  and  electronic  counter¬ 
measures  (ECM) 

g.  Enhancing  system  survivability 

h.  Designing  reliability  and  logistic  supportability  into 
the  system 


Acquisition  Strategy  Update  During  the  FSD  Phase.  During  the  FSD 
Phased  the  PM  should  conduct  a  comprehensive  review  of  the  acquisition 
strategy  and  Functional  Implementation  Plans  (FIPs)  (see  later  in  this 
Section)  in  conjunction  with  a  review  of  the  decision  authority's  Mile¬ 
stone  II  decision  memorandum.  A  procedure  for  this  review  is  discussed 
under  "Organizing  DSV  Phase  Activities"  (see  Section  3).  The  updated 
acquisition  strategy  should  include  discussions  on  the  following  items: 

1.  Work  Breakdown  Structure  (WBS).  Delineate  the  level  to  which 
each  breakdown  is  to  be  managed  and  for  which  cost  reports  are  to  be 
obtained.  Also,  establish  the  schedule  of  review  (weekly,  monthly,  or 
quarterly,  depending  on  criticality  of  the  schedule  or  the  degree  of 
risk  in  the  individual  breakdown). 
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2.  Life-Cycle  Cost  (LCC).  Review  and  discuss  the  cost  models, 
costing  methods,  and  data  review  sources  used  in  validating  the  esti¬ 
mate. 


3.  Management  review  and  Tracking  Procedures-.  Discuss  the  proce¬ 
dures  to  be  used  in  tracking  the  progress  of  critical  project  activi¬ 
ties;  e.g.,  updating  the  TEMP,  1LSP,  FIPs,  etc. 

4.  Risk  Management.  Reaffirm  responsibility  assignments  for  man¬ 
aging  all  facets  of  the  project  with  special  attention  to  high-risk 
areas.  Review  the  status  of  currently  identified  risk  areas  to  ensure 
that  actions  are  planned  to  resolve  risk  areas.  This  may  require  addi¬ 
tional  laboratory  tests  and  simulations,  the  establishments  of  “Tiger" 
teams,  or  the  initiation  of  a  redundant  effort  by  other  contractors  or 
by  Navy  laboratories.  The  Total  Risk  Assessment  Cost  Estimate  (TRACE), 
Program  Evaluation  Review  Technique  (PERT),  or  other  management  systems 
are  useful  for  this  purpose. 

5.  Competition  in  Production.  Production  competition  has,  until 
recently,  been  at  the  option  of  the  PM.  The  trend  now  is  to  structure  a 
competitive  strategy  or  have  solid,  unassailable  justification  for  sole 
source.  The  decision  to  compete  or  not  revolves  primarily  around:  (1) 
the  cost  of  establishing  and/or  qualifying  a  second  source;  (2)  the 
quantity  of  production  units  to  be  procured;  and  (3)  the  duration  of  the 
production  phase,  i.e.,  the  number  of  years  in  which  follow-on  produc¬ 
tion  contracts  will  be  awarded. 

If  production  competition  is  to  be  pursued,  a  method  of  technology 
transfer  must  be  selected.  Alternative  methods  include  Form-Fit-Func- 
tion.  Technical  Data  Package,  Directed  Licensing,  Leader-Follower  and 
Contractor  Teaming. 

Factors  which  must  be  considered  to  determine  the  most  appropriate 
method  include  the  quantity  to  be  procured,  duration  of  production, 
complexity  of  the  system,  availability  of  data  rights  and  maintenance 
philosophy  for  the  system  among  others. 

Additional  considerations  include  the  "mechanics"  of  selecting, 
educating  and  qualifying  a  second  source,  and  the  role  the  first  source 
should  play  in  the  process;  whether  to  use  annual  or  multi-year  produc¬ 
tion  buys;  whether  to  award  production  contracts  on  a  winner-take-all  or 
split-quantity  basis,  etc. 

The  PM  should  understand  that  the  prime  contractor  will  usually  see 
the  prospect  of  a  second  source  (i.e.,  competition  in  production)  as  an 
unfavorable  development.  Therefore,  the  inclination  of  the  prime  will 
be  to  develop  a  strategy  which  will  make  a  second  source  unattractive. 
Competition  often  results  in  a  better  product  and  better  pricing.  There 
is,  however,  a  significant  cost  associated  with  establishing  a  second 
production  source.  Therefore,  the  PM  must  determine  analytically  early 
in  his  program  whether  the  benefits  outweigh  the  costs.  If  so,  he 
should  plan  for  that  competition,  should  properly  fund  for  initial 
second-source  startup  costs,  and  make  sure  that  these  funds  remain 
intact.  He  should  be  vigilant  with  regard  to  any  action  which  would 
impede  competition.  Where  competition  in  production  is  planned,  the  PM 
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is  strongly  advised  to  prohibit  proprietary  claims  that  would  preclude 
second-source  production. 

6.  Component  Breakout.  Another  means  of  introducing  or  maintain¬ 
ing  competition  is  to  require  breakout  of  major  subsystems  or  components 
for  competitive  procurement.  These  items  may  then  be  furnished  to  the 
prime  contractor  as  GFM/GFE  (see  Section  3).  Normally,  it  is  not  desir¬ 
able  to  allow  the  prime  contractor  to  purchase  these  major  components 
unless  the  prime  has  expertise  that  justifies  the  substantial  additional 
cost  for  handling  (up  to  50%)  plus  profit.  In  some  cases,  it  may  be 
desirable  for  the  Navy  to  act  as  system  integrator. 

7.  Design  Ownership.  Within  the  acquisition  strategy,  the  issue 
of  design  ownership  and  the  use  of  proprietary  components  should  be 
addressed  early.  The  issue  can  be  controversial  and  politically  sensi¬ 
tive  and  should  be  resolved  with  a  well-justified,  documented  decision. 
The  lower  the  level  of  design  ownership  by  the  government,  the  more 
expensive  and  difficult  that  ownership  becomes.  Specifically,  the  gov¬ 
ernment  must  procure  more  documentation  and  must  assume  the  responsibi¬ 
lity  for  its  accuracy  when  its  use  is  made  mandatory  in  the  production 
of  an  item.  If  proprietary  parts  and  processes  associated  with  items 
using  sophisticated  technologies  are  not  excluded  from  the  government- 
owned  portion  of  the  design,  the  government  must  obtain  license  and 
documentation  for  those  parts  and  processes  or  be  satisfied  with  a 
permanent  sole-source  situation,  thereby  lessening  the  advantage  of 
design  ownership.  The  government  must  develop  rigid  acceptance  tests 
when  internal  proprietary  components  are  used  by  the  contractor,  as 
these  components  are  not  subject  to  direct  government  control  and  may  be 
changed  at  the  vendor's  discretion. 


Establishment  of  the  Baseline  Plan 

A  good  baseline  plan  is  essential  to  the  effective  management  of  a 
program.  It  is  the  PM's  perception  of  where  he  is  going  and  it  is  not 
only  necessary  that  the  baseline  plan  be  complete,  but  that  it  also  be 
organized  in  such  a  fashion  that  it  can  be  readily  used.  In  particular, 
it  is  important  that  the  structure  of  the  baseline  plan  displays  the 
relationship  among  various  project  elements  clearly  and  present  a  suit¬ 
able  matrix  for  organizing  compatible  accounting  and  other  reporting 
systems . 


The  accepted  method  for  achieving  a  suitable  organized  baseline  is 
through  the  use  of  the  work  breakdown  structure  (WBS).  It  is  an  ex¬ 
tremely  useful  tool  fur  organizing  the  baseline,  for  structuring  ac¬ 
counting  and  other  reporting  and  assignment  systems,  and  for  use  in 
other  applications  such  as  life-cyclo  costing.  If  properly  conceived 
and  employed  it  can  be  the  key  to  effective  operation  of  the  management 
process. 


Work  Breakdown  Structure  (W3S).  MIL-STD  881  defines  a  WBS  as  "a 
product-oriented  fami ly  tree  composed,  of  hardware,  services  and  data 
with  result  from  project  engineering  efforts  during  the  development  and 
production  of  a  defense  material  item,  and  which  completely  defines  the 
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project/program.  A  WBS  displays  and  defines  the  product (s)  to  be  devel¬ 
oped  or  produced  and  relates  the  elements  of  work  to  be  accomplished  to 
each  other  and  to  the  end  product." 

The  WBS  provides  a  technique  for  subdividing  a  total  program  or 
portion  thereof  into  its  component  elements.  These  can  then  be  display¬ 
ed  in  a  manner  that  shows  their  relationship  to  each  other  and  to  the 
whole.  It  is  a  basic  framework  which  assists  in  systematic  organization 
for  program  planning  and  management  control  at  all  levels  of  management. 

The  way  to  develop  a  WBS  is  described  in  MIL-STD  881  and  deviations 
from  this  standard  must  be  identified  and  explained  in  the  Integrated 
Program  Summary  (IPS)  (see  page  3-XX).  The  WBS  is  organized  in  tiers, 
or  LEVELS,  each  composed  of  a  number  of  discrete  items,  or  ELEMENTS. 
The  top  tier,  a  single  element,  is  Level  1,  the  next,  Level  2,  etc., 
with  the  elements  of  each  succeeding  level  being  subdivisions  of  the 
elements  of  the  preceding  level.  An  example  is  provided  in  Figure  4-3. 

Program  Summary  WBS.  While  a  WBS  can,  theoretically,  be  carried  to 
almost  any  level  of  detail,  it  can  quickly  become  too  cumbersome  and 
unwieldy  to  be  of  practical  use  if  carried  too  far.  For  this  reason, 
the  WBS  most  used  by  PM  is  an  abbreviated  version  called  the  Program 
Summary  WBS.  The  Program  Summary  WBS  usually  consists  of  the  first 
three  levels  of  the  WBS.  In  some  instances,  portions  of  the  Program 
Summary  WBS  may  be  extended  to  the  forth  level,  but  rarely  beyond  that. 
Such  a  Program  Summary  WBS  will  identify  the  "hardware"  elements  of  the 
program  and  their  subsystems  (these  elements  are  sometimes  called  "mis¬ 
sion  hardware"  elements)  and  the  elements  necessary,  at  the  system 
level,  to  support  the  development,  production,  and  service  use  of  those 
products  (these  support  elements  are  sometimes  called  "generic"  ele¬ 
ments).  The  level  to  which  the  Program  Summary  WBS  is  carried  will 
probably  be  determined  by  the  levels  of  the  elements  where  the  PM  plans 
to  assign  major  responsibility  to  a  contractor  or  to  a  Navy  Field  Acti¬ 
vity  or  other  government  organization. 

Contract  or  Subprogram  WBS.  When  a  PM  decides  to  assign  responsi¬ 
bility  For  tHe  effort  and  the  results  to  be  achieved  under  a  given 
Program  Summary  WBS  element  to  a  contractor,  DOD  policy  dictates  that, 
for  any  sizable  effort,  a  separate  "Contract"  WBS  be  developed  for  that 
effort.  The  Program  Summary  WBS  element  representing  that  effort  will 
be  the  first  level  element  in  the  new  WBS.  frequently,  the  development 
of  the  Contract  WBS  is  a  two-step  process. 

The  first  step  is  the  development  of  a  normal,  three-level  WBS  to 
be  included  as  a  part  of  the  contract  specification  to  assist  in  defin¬ 
ing  the  scope  of  the  effort  desired.  This  Contract  WBS  may  be  modified 
during  negotiation  of  the  contract,  but  should  be  retained  as  a  manage¬ 
ment  tool  during  contract  execution. 

After  the  contract  has  been  let  or,  in  some  instances,  during  its 
negotiation,  the  contractor  should  be  required  to  expand  the  Contract 
WBS  to  additional  levels  of  detail.  The  amount  of  expansion  will  depend 
upon  the  level  to  which  visibility  is  desired  and  control  is  to  be 
exercised. 
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FIGURE  4-3,  Three-Level  Work  Breakdown  Structure  (WBS) 


In  those  instances  where  responsibility  for  a  major  Program  Summary 
WBS  element  is  assigned  to  a  field  activity,  a  Subprogram  WBS  should  be 
developed  in  cooperation  between  the  field  activity  and  the  program 
management  office  (PMO).  It  should  be  used  for  the  same  purposes  and  in 
a  similar  manner  to  the  Contract  WBS.  Any  comments  made  concerning  the 
Contract  WBS  will,  normally,  be  equally  applicable  to  the  Subprogram 
WBS. 


A  Contract  WBS  will  usually  emanate  from  a  mission  hardware  element 
of  the  Program  Summary  WBS.  Such  a  Contract  WBS  will  contain  both 
mission  hardware  elements  and  generic  elements,  the  former  being  further 
hardware  breakdowns  and  the  latter  representing  the  support  required  at 
the*  hardware  subsystem  level  from  which  the  WBS  is  being  developed.  A 
useful  tool  for  assuring  that  all  the  proper  generic  elements  are  in¬ 
cluded  is  a  WBS  element  matrix,  as  shown  in  Figure  4-4,  in  which  the 
mission  hardware  elements  of  the  Project  Summary  WBS  are  along  one  axis 
of  the  matrix  and  the  generic  elements  are  along  the  other.  This  allows 
ready  visualization  of  all  generic  elements  that  might  be  involved,  for 
decision  as  to  whether  or  not  they  are  required  at  that  subsystem  level. 

Program  WBS.  The  complete  WBS  for  the  program  is  made  up  of  the 
Program  Summary" WBS  plus  all  of  the  Contract/Subprogram  WBSs  emanating 
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from  it.  This  Program  WBS  forms  the  framework  within  which  the  baseline 
plan  is  developed  and  the  rest  of  the  management  process  is  executed. 
Note  that  a  Contract  (or  Subprogram)  WBS  may  be  the  expansion  of  an 
element  in  another  Contract  (or  Subprogram)  WBS  if  the  manner  in  which 
responsibilities  are  delegated  and  the  requirement  for  visibility  and 
control  make  It  desirable  to  do  so. 


Assignment  of  Responsibilities.  Obviously,  no  person  can  do  every- 
thing,  or  even  oversee  every  detail  in  a  program  of  any  size  or  complex¬ 
ity.  The  PM  must  therefore  delegate  responsibility  for  various  aspects 
of  the  program  and  he  must  do  this  in  a  logical,  unambiguous  manner. 
The  WBS  breaks  out  program  objectives  and  functions  in  a  way  that  sim¬ 
plifies  the  identification  of  specific,  logical  responsibilities  that 
may  be  assigned  to  individuals  or  organizations.  A  useful  tool  for 
applying  the  WBS  to  this  purpose  is  the  accountability  matrix,  as  shown 
in  Figure  4-5,  in  which  WBS  elements  are  displayed  along  one  axis  and 
the  program  organizational  structure  along  the  other.  Use  of  this 
matrix  provides  excellent  visibility  for  logical  assignment,  and  also 
allows  secondary,  support  responsibilities  to  be  displayed/identified  as 
well.  In  some  instances,  use  of  this  matrix  will  assist  In  determining 
the  level  to  which  the  WBS  should  be  carried. 


Plan  Elements.  The  WBS  elements  at  the  lowest  level  in  each  por¬ 
tion  of  the  Program  WBS  form  the  basis  for  the  development  of  detailed 
plans.  (For  reasons  which  will  become  apparent  later,  these  terminal 
elements  are  often  called  COST  ACCOUNTS.)  However,  a  WBS  element  ad¬ 
dresses  program  end-objectives;  what  has  to  be  accomplished,  not  how  it 
is  to  be  done  nor  when  it  is  to  be  done  nor  what  resources  are  required 
to  do  it.  These  latter  items  are,  of  course,  basic  to  any  plan  and  must 
be  addressed  in  relation  to  the  objectives  of  each  cost  account  element. 
This  can  be  done  by  defining  a  series  of  WORK  PACKAGES  associated  with 
each  cost  account. 

Work  Package.  The  Work  Package  is  not  a  further  detailing  of  the 
WBS.  Rather,  it  represents  a  portion  of  the  actual  work  that  must  be 
done  to  achieve  the  objectives  related  to  the  associated  cost  account 
element.  Each  Work  Package  represents  a  unique  segment  of  the  work  to 
be  done  at  the  level  where  it  is  to  be  performed.  It  defines  the 
activities  which  must  be  completed  to  achieve  a  specific  physical  accom¬ 
plishment.  Obviously,  for  it  ot  be  unique,  the  start  of  any  Work  Pack¬ 
age  effort  must  be  based  on  some  other,  external,  physical  accomplish¬ 
ment.  The  time  it  will  take  and  the  resources  necessary  to  carry  out 
each  activity  can  be  estimated  fairly  accurately  and,  hence,  a  schedule 
and  a  budget  can  be  established  for  the  Work  Package.  This  in  turn  can 
be  integrated  into  the  overall  program  schedule.  Additionally,  in  order 
to  make  achievement  more  visible  and  easier  to  manage,  each  Work  package 
should  span  a  relatively  short  period  of  time  and  should  be  assigned  to 
a  single  individual  or  organizational  segment. 

Level  of  Effort  (LOE)  Package.  Unfortunately,  in  every  program 
there  are  certain  types  of  effort  that  cannot  be  fitted  into  a  true  Work 
Package.  Generally,  these  efforts  do  not  result  in  a  specific  identifi¬ 
able  physical  accomplishment  and  tend  to  span  all,  or  major  portions  of 
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FIGURE  4-5.  Accountability  Matrix 


a  program  schedule.  Day-to-Day  program  management  is  a  good  example  of 
this  type  of  effort.  Even  though  there  may  appear  to  be  no  tangible, 
objective-oriented  achievements  from  these  LOE  packages,  they  are  neces¬ 
sary  and  they  do  consume  resources,  so  they  must  be  included  or  account¬ 
ed  for  in  any  plan.  However,  care  must  be  taken  to, assure  that  any  LOE 
Packages  that  are  included  are,  indeed,  LOE  and  not  the  mis-definition 
of  one  or  a  series  of  Work  Packages.  Because  it  is  usually  more  diffi¬ 
cult  to  specify  LOE  Packages,  it  is  more  difficult  to  control  the  effort 
that  may  be  attributed  to  such  Packages. 

Plan  Integration.  Once  all  the  requisite  Work  Packages  and  LOE 
Package?  have  Been  identified  and  defined  and  the  time  span,  resource 
requirements,  and  interrelationships  have  been  specified  for  all  the 
related  activities,  they  can  all  be  put  together  into  a  master  baseline 
plan  for  the  program.  In  theory,  this  is  a  relatively  simple  matter, 
although  perhaps  a  bit  tedious  for  a  large  program.  In  practice,  it  is 
not  all  that  easy  unless  computerized  "management  systems"  are  used. 
Indeed,  DOD  policy  (DODD  7000.1  et  seq)  requires  that  contractors  on 
major  programs  utilize  a  "Cost  Schedule  Control  System"  that  satisfies 
specific,  detailed  criteria.  No  such  requirement  is  currently  placed  on 
government  activities  (although  there  may  be  some  faint  stirrings  in 
that  direction),  but  it  is  reasonable  that  the  PM  do  so  for  his  program. 
The  systems  used  by  all  major  participants  in  a  program  need  not  (and 
perhaps,  should  not)  be  identical,  but  the  output  data  provided  by  each 
to  the  PMO  should  be  similar  in  content,  if  not  in  format.  Just  what 
that  output  should  be  is  defined  in  DOD  instructions  and  will  only  be 
outlined  briefly  here. 

Budget.  Estimated  costs  of  the  effort  defined  in  the  Work  (and 
LOE)  Packages  should  be  accumulated  at  the  cost  account  level.  These 
can,  and  should,  then  be  combined  to  provide  budgets  at  higher  levels 
(contract  or  subprogram)  up  to  the  total  program.  These  should  be 
capable  of  being  broken  out  by  various  types  of  cost  (labor  and  over¬ 
head,  materials,  procurement/contracts,  travel,  etc.)  as  appropriate  to 
the  program  and  the  level  of  accumulation.  Especially  important  is  the 
ability  to  identify  the  estimated  cost  of  the  effort  scheduled  to  be 
accomplished  at  any  point  in  time.  DOD  usage  terms  this  "Budget  Cost  of 
Work  Scheduled"  (BCWS)  and  it  is  used  in  later  steps  of  the  management 
process. 

Schedule.  Each  Work  Package  activity  will  have  a  scheduled  start 
and  completion  date,  determined  by  the  interface  relations  with  other 
activities.  These  activities,  in  turn,  may  be  accumulated  and  summariz¬ 
ed  to  provide  manageable  schedules  at  higher  levels.  An  important 
adjunct  to  any  schedule  is  an  indication  of  hew  important  it  is  to 
complete  any  given  activity  on  schedule. 

Most  "management  systems"  used  in  plan  synthesis  will  determine, 
for  each  activity,  how  long  the  completion  of  that  activity  may  be 
delayed  before  it  will  cause  the  end-date  of  the  program,  or  program 
segment,  to  slip.  This  quantity  is  variously  called  "slack"  or  "safety" 
or  something  similar,  depending  on  the  system  or  local  usage.  Obvious¬ 
ly,  the  completion  of  those  activities  for  which  this  quantity  is  zero 
is  critical  to  the  completion  of  the  program  on  schedule.  Hence,  any 
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activity  having  a  zero  slack  is  said  to  lie  on  (or  be  a  part  of)  a 
CRITICAL  PATH.  It's  delineation  is  a  very  useful  feature  and  should  be 
required. 

Program  end  objectives  are  identified  in  the  development  of  the 
WBS.  In  the  development  of  the  plan,  intermediate  objectives  are  either 
imposed  on  the  plan  or  arise  out  of  logical  plan  development.  It  is 
useful  to  identify  and  display  these  as  "milestones"  in  the  plan  with 
scheduled  dates  of  accomplishment.  The  best  known  of  these  milestones 
are  the  major  review/decision  point  milestones  separating  program  phases 
and  defined  in  DODD  5000.1.  Other  milestones  are  intermediate  to  these 
and,  more  often  than  not,  represent  achievement  in  only  one  facet  of  the 
program.  The  identification  and  use  of  milestones  is  valuable  in  pro¬ 
viding  short-term  incentives  and  additional  visibility  for  specific 
technical  achievements. 

Responsibilities.  The  assignment  of  responsibilities  to  the  cost 
account  level  was  discussed  above  (Assignment  of  Responsibilities^ 
These  assignments,  extended,  perhaps,  to  the  Work  Package  or  activity 
level,  should  be  integral  to  the  plan. 


Measurement  of  Progress 

The  third  step  in  the  management  process  is  the  determination  or 
measurement  of  progress  made.  In  general ,  there  are  two  aspects  of 
progress  that  need  to  be  determined,  resource  expenditure  and  technical 
accomplishment.  The  PM  must  avoid  the  tendency  to  develop  unique  re¬ 
ports  when  existing  data/reports  are  adequate  to  ensure  control. 

Resource  Expenditure.  Resources  whose  expenditures  should  be  mea- 
sured  include  funds,  manpower,  materials  and  services.  In  some  cases, 
the  latter  three  may  be  considered  to  be  subsets  of  the  first  and  their 
expenditure  measured  or  recorded  indirectly  in  terms  of  monetary  costs. 
In  others,  they  may  be  determined  more  directly.  In  any  case,  it  is 
essential  that  the  system  established  to  measure  and  record  these  quan¬ 
tities  be  structured  in  such  a  manner  that  the  measured  values  can  be 
used  directly  and  readily  in  the  comparison,  analysis,  and  decision 
phases  of  the  management  process. 

Fund  Expenditures.  The  WBS  which  is  used  in  structuring  and  devel¬ 
oping  the  baseline  plan  should  be  used  directly  in  structuring  the 
accounting  system  for  recording  costs  relative  to  accomplishment.  For 
this  purpose,  an  account  should  be  set  up  in  the  accounting  system  of 
the  responsible  organization  to  accumulate  the  costs  of  all  effort 
associated  with  each  of  the  terminal  WBS  elements  for  which  that  organi¬ 
zation  has  been  assigned  responsibility  (hence  the  term  COST  ACCOUNT  for 
these  terminal  elements). 

Other  Resource  Expenditures.  Accumulation/recording  of  these  ex¬ 
penditures  should  be  organized  by  WBS  cost  account  elements  in  the  same 
manner  as  for  costs.  Indeed,  if  reporting  of  these  expenditures  by 
their  cost  is  sufficient,  the  whole  thing  can  undoubtedly  be  done  by  the 
same  accounting  system.  If,  on  the  other  hand,  man-hours  or  numbers  of 
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hardware  components  or  the  like  is  required,  some  other  system  may  be 
necessary.  Any  major  contractor  or  government  field  activity  will  have 
the  capability  to  do  this,  but  the  requirement  must  be  specified  from 
the  outset  to  preclude  confusion  and/or  costs  at  some  later  date. 

Technical  Accomplishment.  Technical  accomplishment  should  be  mea¬ 
sured  at  the  Work  Package  activity  level.  Two  aspects  of  activity 
accomplishment  must  be  determined;  first,  how  much  of  the  activity  has 
been  completed  and,  second,  what  the  results  of  that  completion  were. 

Measure  of  Activity  Completed.  In  some  instances,  the  measurement 
of  activity  completion  can  be  a  relatively  subjective  determination,  so 
the  best  estimate  will  usually  come  from  the  individual  actually  doing 
the  work.  The  question  asked  should  not  be  "how  much  of  the  activity 
has  been  completed?"  but  rather,  "how  long  will  it  take  to  complete  the 
activity?"  In  theory,  these  two  questions  may  seem  to  be  equivalent. 
In  practice,  the  answers  frequently  are  not;  and  the  second  question  is 
really  the  one  that  is  more  significant  in  assessing  program  status. 
For  use  at  the  program  level,  it  is  usually  advantages  to  translate  this 
time-based  status  indication  into  one  with  a  monetary  base  which,  in  DOD 
parlance,  is  called  "Budgetary  Cost  of  Work  Performed"  (BCWP). 

8CWP  is  what  had  been  planned  to  be  spent  for  the  effort  actually 
accomplished  and,  when  combined  with  other  factors  to  be  discussed 
later,  can  be  a  very  powerful  indication  of  the  relative  "health"  of  the 
program.  Every  contractor  with  an  approved  Cost/Schedule  Control  System 
has  an  "acceptable"  method  for  determining  this  quantity.  It  is  abso¬ 
lutely  necessary  for  the  PMO  to  understand  just  what  that  method  is  in 
order  to  use  the  indicator  effectively. 

One  method  involves  assigning  50%  of  the  budgeted  cost  to  an  acti¬ 
vity  as  soon  as  effort  under  the  activity  is  started.  The  remaining  50% 
is  assigned  only  when  the  effort  is  completed.  This  is  a  simple  method 
to  implement  and,  where  relatively  short-span  low-cost  activities  are 
involved,  it  is  probably  reasonably  accurate.  However,  in  instances 
where  spans  of  significant  length  are  associated  with  significant  costs, 
"lead-lag"  situations  can  occur  which  may  distort  the  true  picture. 

Another  method  involves  assigning  a  percentage  of  cost  equal  to  the 
percentage  of  the  activity  estimated  to  have  been  completed  (that  is, 
assume  costs  to  be  linear  with  time).  This  can  be  a  more  reasonable 
approximation  so  long  as  activities  have  not  been  assigned  in  too  gross 
a  manner  and  significant  material  costs  are  not  involved.  In  the  first 
case,  it  is  probably  wise  to  have  each  activity  examined  to  assure  that 
it  is  really  a  homogeneous  entity.  (For  example,  an  8-week  activity 
labeled  "test"  might  really  consist  of  3  weeks  of  test  planning  and 
preparation  at  a  low  level  of  effort,  2  weeks  of  intense  activity  for 
actual  testing,  and  3  weeks  of  more  moderate  effort  in  data  reduction, 
assessment  and  report  preparation.  For  better  visibility  and  more 
positive  control,  it  would  probably  be  better  to  break  the  one  activity 
into  three.)  In  the  case  of  material  costs,  it  is  probably  desirable 
that  they  be  assigned  separately  in  a  manner  analogous  to  that  in  which 
actual  costs  are  accumulated,  since  comparison  is  usually  more  signifi¬ 
cant  than  absolute  value. 


Verification  of  Results.  In  most  well -planned  programs,  means  to 
verify  that  the  results  specified  for  the  program  effort  are  being 
achieved  are  built  into  the  program.  Indeed,  a  major  portion  of  any 
acquisition  program  is  devoted  to  demonstrating  that  the  system-of-the- 
moment  meets  -  or  does  not  meet  -  program  objectives.  For  example,  if  a 
Work  Package  consists  of  a  design-fabri cate-test  cycle  for  some  compo¬ 
nent,  the  sole  purpose  of  the  fabricate  and  test  activities  is,  probab¬ 
ly,  to  verify  that  the  design  satisfies  program/system  requirements.  It 
is  still  necessary,  however,  to  assure  that  the  plans  for  tests  and 
numbers  of  units  to  be  tested  are  satisfactory,  that  test  items  are 
properly  built  to  adequate  documentation,  and  that  the  tests  are  carried 
out  as  planned. 

The  most  obvious  method  for  gathering  this  information  efficiently 
is  by  means  of  periodic  review  meetings  where  technical  progress  can  be 
reported  and  discussed.  These  can  be  held  at  almost  any  level  of  the 
program  -  element,  contract/subprogram,  program.  They  can  also  be  held 
for  the  discussion  of  a  single  problem  and  at  intermediate  times  when  it 
appears  desirable  to  do  so. 

The  achievement  of  a  milestone  is  a  significant  event  in  program 
effort  and  must  be  recognized.  However,  intermediate  milestone  attain¬ 
ment  must  be  used  carefully,  in  conjunction  with  other  measures,  in 
assessing  program  status  to  assure  that  the  aura  surrounding  such  an 
event  does  not  obscure  deficiencies  in  other,  unrelated  portions  of  the 
program. 

Comparison  of  Progress  with  Baseline 

This  step  consists,  essentially,  of  comparing  the  results  of  the 
first  two  steps  against  each  other.  In  any  very  large  or  complex  pro¬ 
ject,  the  problem  is  to  present  these  results  in  a  manner  that  makes 
differences  between  the  two  visible  and  meaningful.  General  means  for 
doing  this  include  the  use  of  numerical  indicators  and  graphical  repre¬ 
sentation. 

Numerical  Indicators.  There  are  several  numerical  indicators  that 
can  be  very  significant  in  any  comparison  of  progress  to  plan.  Three  of 
these  are  measured  in  dollars,  allowing  unambiguous  comparison.  They 
include  the  BCWS  which  is  included  in  the  plan  information,  the  actual 
cost  of  effort  accomplished  to  that  point  (Actual  Cost  of  Work  Performed 
(ACWP))  which  is  measured  directly  in  the  previous  step,  and  the  trans¬ 
lation  of  technical  progress  to  monetary  terms  discussed  previously, 
8CWP.  These  indicators  should  be  derived  at  the  WBS  cost  account  ele¬ 
ment  level,  but  can  be  combined/accumulated  to  any  higher  level.  Norm¬ 
ally,  the  cost  account  level  will  provide  the  greatest  visibility  and 
understanding.  Among  these  three  indicators,  there  are  two  comparisons 
that  are  very  useful. 

Cost  Variance.  The  comparison  of  ACWP  and  BCWP  is  the  first  of 
these.  The  difference,  BCWP  -  ACWP,  is  called  the  "cost  variance"  and 
is  the  amount  by  which  the  budget  for  the  effort  actually  accomplished 
has  been  underrun  or  overrun.  This  can  be  presented  as  a  percentage,  if 
desired,  by  dividing  by  BCWP  (and  multiplying  by  100).  Cost  variance  is 


often  used  by  the  Secretary  of  the  Navy  (SECNAV)  and  the  Office  of  the 
Secretary  of  Defense  (OSD)  to  track  a  program's  progress.  Significant 
variance  will  probably  result  in  a  request  that  the  PM  explain  the  cause 
of  the  variance  and  what  steps  are  being  taken  to  correct  it. 

Schedule  Variance.  A  similar  comparison  between  BCWP  and  BCWS 
produces  a  numerical  "schedule  variance."  This  indicator  does  not  have 
the  same  type  of  direct  significance  that  the  cost  variance  does,  but  it 
does  provide  a  way  to  highlight  situations  where  effort  is  behind  or 
ahead  of  schedule. 

Caution.  There  is  a  temptation,  if  not  a  tendency,  to  compare  ACWP 
with  BCWS  This  should  be  avoided  as  it  has  no  real  meaning  and  can 
lead  to  erroneous  interpretations  of  program  fiscal  status. 

Critical  Path  Variances.  After  progress  is  entered  against  program 
activities,  a  sort  of  "net  slack"  can  be  calculated  for  any  activity 
that  is  not  on  schedule.  This  quantity  is  derived  from  any  progress  on 
the  activity,  the  original  slack  for  that  activity,  and  the  date  on 
which  status  is  being  determined.  The  significance  of  this  net  slack  is 
exactly  the  same  as  it  was  for  slack  in  the  original  plan,  with  one 
exception.  It  is  possible  to  have  a  negative  value  for  net  slack.  A 
negative  value  means  that  delay  in  the  associated  activity  has  already 
caused  a  slip  in  the  project  end-date  if  nothing  is  done  about  it. 
Obviously,  the  largest  negative  value  represents  the  total  projected 
program  slippage.  Note  that  some  management  systems  do  not  provide  a 
net  slack,  but,  rather,  establish  a  new  schedule  adjusted  to  account  for 
whatever  activity  slippage  there  may  be.  Some  systems  provide  both. 

Graphical  Presentations.  There  are  a  variety  of  ways  in  which  plan 
and  actual  information  may  be  presented  graphically.  In  general,  these 
fall  into  two  different  types,  one  presenting  schedule  information  and 
the  other,  budgetary.  There  are  also  ways  to  combine  the  two  on  a 
single  graph,  but  that  will  not  be  discussed  here. 

Schedule  Graphs.  There  are  two  general  types  of  graphs  commonly 
used  in  presenting  schedule  information,  the  Program  Evaluation  and 
P.eview  Technique  (PERT)  type  network  and  the  Gantt  "bar"  chart.  The 
choice  of  a  graphical  format  depends  on  many  things.  However,  for  the 
display  of  schedules  and  schedule  progress,  some  sort  of  a  bar  chart, 
shaded  to  show  progress  and  with  an  appropriate  symbol  to  indicate 
slack,  probably  provides  the  greatest  visibility  and  ease  in  recognizing 
deviations  from  plan  and  their  significance.  The  bar  chart  may,  also, 
be  best  suited  for  summarizing  the  lowest  level  detailed  charts  into 
charts  presenting  higher  levels  of  aggregation.  However,  the  versatili¬ 
ty  and  genuine  usefulness  of  the  PERT  type  network  in  highlighting 
interactions  and  potential  schedule  problems  make  it  the  preferred 
technique  for  overall  management.  It  is  generally  well  worth  the  cost 
and  effort  required. 

Budgetary  Graphs.  Again,  there  are  a  variety  of  possible  types 
that  may  be  used,  but  the  most  informative  and  readily  understandable 
may  be  the  simple  plot  of  cumulative  expenditures  versus  time.  It  is 
useful  in  this  type  plot,  to  plot  BCWS,  BCWP  and  ACWP  on  the  same  graph. 
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Cost  and  schedule  variances  are  immediately  obvious  as  are  their  rela¬ 
tive  importance.  These  charts  can  also  be  readily  plotted  to  show  any 
level  of  the  program  from  the  individual  cost  account  to  the  entire 
program. 

Technical  Results.  Results  of  tests,  analyses,  or  other  activities 
with  identifiable  outcomes  are  normally  compared  against  performance 
requirements  included  in  or  derived  from  program  objectives.  In  some 
instances,  results  will  be  in  a  "go,  no-go"  mode;  in  others,  actual 
variations  are  measured. 


Analysis  of  Any  Variances  between  Actual  and  Planned  Progress 

Although  it  is  essential  to  recognize  the  existence  of  a  problem, 
it  is  obviously  not  enough.  (The  mathematician  would  say  "it  is  neces¬ 
sary,  but  not  sufficient.")  Additional  information  is  needed:  what 
caused  it  to  occur,  what  will  be  its  impact  on  the  program,  and  what  can 
be  done  about  it.  The  importance  of  thorough  variance  analysis  cannot 
be  overemphasized  since  it  is  critical  in  the  management  of  progress 
made. 


Cost  and  Schedule  Variances.  Analysis  of  these  variances  should  be 
done  at  the  WBS  cost  account  element  level.  Specific  criteria  need  to 
be  established  as  to  when  an  analysis  is  required.  Some  percentage 
variance  threshold  (say  5  to  10%)  is  an  easy  way.  It  is  important  that 
this  limit  be  tight  enough  to  assure  that  incipient  problems  are  identi¬ 
fied  early,  but  at  the  same  time  be  loose  enough  to  prevent  every  norm¬ 
al,  insignificant  perturbation  from  triggering  the  system.  In  practice, 
it  is  probably  wise  to  specify  (in  a  contract  or  a  task  assignment)  a 
threshold  that  is  a  little  more  severe  than  is  necessary  and  then  relax 
it  as  experience  indicates.  The  analysis  itself  must  provide  as  com¬ 
plete  a  picture  as  possible.  As  noted  above,  there  are  at  least  three 
questions  that  must  be  answered: 

1.  Why  did  the  variance  occur?  It  could  be  the  result  of  the 
unavailability  of  some  resource,  manpower  (or  the  right  manpower), 
special  equipment  or  facilities,  or  funds.  It  could  be  the  result  of 
some  technical  difficulty,  either  internal  or  external  to  the  element. 
It  could  be  due  to  delays  in  other  efforts  so  that  inputs  were  not 
available  on  time.  It  could  be  poor  planning.  Whatever  the  reason,  it 
should  be  identified  precisely  and  reported  concisely. 

2.  What  will  be  the  consequences  of  this  variance  if  corrective 
action  is  not  taken?  Cost  overruns  and/or  schedule  slippages  are  common 
results,  but  technical  effect  and  impact  on  the  achievement  of  element 
or  project  objectives  can  also  be  involved.  Again,  the  projected  ef¬ 
fects  should  be  specific  and  reported  briefly. 

3.  What  is  being  or  can  be  done  to  remedy  or  ameliorate  the 
situation?  If  the  situation  can  be  resolved  satisfactorily  within  the 
limits  prescribed  for  the  management  segment  (e.g.,  contractor  or  field 
activity)  responsible,  the  solution  should,  normally,  be  implemented  at 


that  level  and  be  reported  promptly.  (The  PM  obviously,  may  veto  that 
approach  and  require  another.)  If  the  solution  lies  outside  the  bounds 
of  the  authority  delegated,  the  various  options  available  should  be 
identified  and  presented  to  the  manager  having  that  authority  for  deci¬ 
sion. 


Normally,  the  measurement/analysis  process  involving  the  cost  and 
schedule  variables  will  be  performed  at  regular  intervals  (perhaps 
monthly),  but  a  special  report  could  be  requested  at  any  time  that 
external  influences  or  technical  problems  make  it  desirable. 

In  addition  to  the  cost  and  schedule  effects  at  the  cost  account 
level,  they  should  also  be  projected  for  the  entire  contract  or  subpro¬ 
gram  for  eventual  incorporation  into  overall  program  estimates. 

Estimated  Cost  at  Completion  (EAC).  This  is  an  important  parameter 
in  most  programs,  the  "bottom  line"  as  it  were.  This  consists  of  a 
known  quantity  (ACWP)  plus  an  estimate  of  costs  to  be  incurred  over  the 
rest  of  the  program.  This  estimate  can  be  made  in  a  number  of  ways,  any 
one  of  which  may  be  reasonable.  It  is  important,  however,  that  the 
method  used  be  known  to  the  PM,  and  that  the  reason  for  its  selection 
are  logical  for  that  program. 

One  method  is  to  re-examine  all  activities  not  yet  completed  and 
re-estimate  what  each  will  cost.  This  is  cumbersome  and  may  not  be 
worth  the  effort,  since  individuals  do  not  always  learn  from  experience. 

A  srcond  method  assumes  that  cost  experience  to  date  will  be  exact¬ 
ly  reflected  in  future  efforts.  That  is,  if  the  effort  under  a  given 
cost  account  has,  to  date,  cost  20%  more  than  was  planned  for  it 
(ACWP/BCWP  =  1.2),  then  the  EAC  for  that  cost  account  will  be  20%  more 
than  originally  budgeted.  The  EAC  for  the  total  contract  or  subprogram 
of  the  program  as  a  whole  will,  then,  be  the  sum  of  the  EACs  for  the 
individual  cost  accounts.  This  is  relatively  easy  to  apply  and  is 
probably  accurate  method  if  any  unusual  circumstances  (either  past  or 
future)  are  identified  and  proper  adjustment  made. 

A  simpler,  although,  possibly,  a  little  less  accurate  version  of 
the  second  method  would  use  the  ACWP/BCWP  ratio  for  the  entire  contract/ 
subprogram  as  a  multiplier  for  cost  estimates  of  all  future  effort. 

Analysis  of  Technical  Variance.  This  is  probably  the  most  crucial 
type  of  analysis  involved  in  the  management  process.  It  is  the  one 
where  assistance  of  other  technical  experts  may  be  required  (Navy  field 
activities  provide  a  good  source).  It  may  also  require  some  restructur¬ 
ing  of  the  program  merely  to  determine  the  cause  of  the  variance.  Note 
that  any  significant  technical  variance  will  always  result  in  cost  and 
schedule  variances.  The  converse  is  not  true.  Note,  also,  that  any 
significant  technical  variance  should  be  reported  immediately  without 
waiting  for  normal  periodic  reports,  and  the  necessary  analysis  should 
be  started  at  once. 

As  with  other  variances,  the  same  questions  need  to  be  answered; 
What  caused  it?  What  is  its  impact?  and,  What  can  be  done  about  it? 
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Making  Corrections 

This  is  the  pivotal  step  in  the  management  process,  the  decision 
point.  On  the  one  hand,  it  is  the  culmination  of  one  planning,  measur¬ 
ing,  analyzing  cycle  and,  on  the  other,  it  is  the  beginning  of  the  next 
cycle,  since  normally  it  results  in  some  modification  to  the  baseline. 
This  is  also  the  step  that  makes  the  PM  "earn  his  pay".  He  should 
remember  that  he  is  not  working  alone  and  that  he  has  many  resources 
both  within  and  outside  the  Department  of  the  Navy  (DON)  to  assist  him. 
It  is  particularly  important  that  the  PM  listen  to  the  staff  and  the 
Government  support  activities  prior  to  making  his  key  decisions.  It  is 
essential  that  his  decisions  be  logical,  be  based  on  the  best  technical 
advice,  and  be  timely.  The  success  or  failure  of  the  program  depends 
upon  this. 


CONTRACTING 
Contracting  Process 

As  noted  earlier,  the  PM  must  assign  responsibilities  for  various 
portions  of  the  program  to  organizations  outside  the  PMQ.  Navy  acquisi¬ 
tion  policy  requires  that  industry  be  relied  upon  heavily  during  the 
development  stages  of  a  program  and  almost  completely  for  production. 
However,  the  government  has  certain  responsibilities  which  cannot  be 
assigned  to  industry.  These  include  the  determination  of  agency  needs, 
sufficiency  of  the  technology  base,  effective  program  management,  and 
decisions  as  to  operational  use.  Similarly,  industry,  in  general,  has 
responsibilities  in  the  acquisition  process:  providing  the  requisite 
technical  capability,  competently  managing  their  resources,  and  devel¬ 
oping  and  maintaining  the  capacity  to  economically  produce  the  item. 
The  specific  responsibilities  of  industry  are  those  defined  by  contract. 

The  contract  establishes  the  relationship  between  government  end 
industry.  It  must  define  the  objectives,  responsibilities,  and  authori¬ 
ty  of  each  party  and  provide  positive  control  with  adequate  flexibility 
for  timely  modifications.  Figure  4-6  illustrates  the  government/industry 
relationship.  The  key  to  program  success  is  a  "good"  contract. 


I  INDUSTRY  RESPONSIBILITIES 

|  •  TECHNICAL  capability 

I  •  MANAGEMENT 

!  •  PRODUCTION 


FIGURE  4-6.  Government/Industry  Relationship. 
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in  one  sense,  the  management  of  contracted  effort  is.  no  different 
than  for  any  other  effort.  The  five-step  management  procedure  discussed 
under  “The  Management  Process"  in  this  Guide  is  certainly  applicable.  In 
another  sense,  however,  contracted  effort  is  very  different.  The  legal 
aspects  of  the  contract  and  all  the  contracting  process  impose  con¬ 
straints  that  must  be  understood  and  observed  by  all  parties  to  the 
contract.  The  PM  must  recognize  that  the  contractor's  incentives  are, 
naturally,  different  in  some  respects  from  those  of  the  government  and 
his  understanding  and  appreciation  of  operational  requirements  and  con¬ 
straints  on  the  product  are  probably  imperfect,  at  best.  Considering 
these  together,  several  points  deserve  emphasis: 

1.  The  PM  bears  the  ultimate  responsibility  for  meeting  program 
objectives,  not  the  contractor. 

2.  Contract  provisions  and  language  must  assure  that  the  PM  and 
his  technical  management  representatives  can  exercise  the  necessary 
control  over  the  contract  effort,  Especially  important  are  plan  appro¬ 
val,  monitoring  of  effort,  and  the  making  of  significant  decisions. 

3.  The  PM  must  rot  surrender  any  of  his  prerogatives  to  the  con¬ 
tractor  -  something  easy  to  do  through  inattention  or  inaction. 

4.  It  is  imperative  that  the  PM  have  technically  competent  gov¬ 
ernment  personnel  to  advise  and  assist  him. 

5.  The  contracting  process  is  time  consuming.  A  multitude  of 
legal  and  procedural  requirements  must  be  met.  The  PM  must  recognize 
this,  provide  the  requisite  time  for  these  actions  in  his  plans,  and, 
with  his  team,  exert  pressure  at  all  time  to  keep  the  process  on  sche¬ 
dule. 

6.  The  PM  should  be  directly  involved  in: 

o  Developing  a  contracting  (procurement)  team 

o  Selecting  sources  and  negotiating  contracts 

o  Fostering  competition 

o  Managing  contracts 


Types  of  Contracts 

It  is  Department  of  Defense  policy  that  contract  types  be  employed 
that  are  appropriate,  considering  all  the  facts  and  circumstances  invol¬ 
ved  in  a  specific  acquisition.  The  principal  distinction  between  vari¬ 
ous  contract  types  lies  in  the  degree  of  risk  assumed  by  the  parties  and 
in  the  apportionment  of  responsibility.  To  the  extent  that  the  selected 
contract  type  reflects  a  fair  and  reasonable  apportionment  of  risk  and 
responsibility  between  the  government  and  the  contractor,  the  contract 
is  more  likely  to  facilitate  the  efficient  conduct  of  a  program.  When 
unilaterally  imposed  as  a  substitute  for  effective  program  management, 
either  by  inadvertence  or  by  design,  an  inappropriate  contract  becomes 
the  source  of  needless,  unproduct i ver  and  costly  controversy. 

It  makes  little  sense  to  place  unreasonable  risk  upon  industry  by 
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means  of  firm  commitment  negotiated  at  high  prices,  but  unenforceable  in 
practice  or  in  fact.  Firm  commitments  at  high  prices  tend  to  make  total 
acquisition  program  unaffordable,  and  attempts  to  enforce  such  contracts 
may  generate  senseless  adversarial  relationships  that  are  almost  inevi¬ 
tably  detrimental  to  the  interest  of  all  the  parties. 

Basically,  there  are  two  types  of  contracts:  fixed-price  and  cost- 
reimbursement.  The  major  distinction  between  the  two  is  in  the  nature 
of  the  seller's  obligation  and  risk.  Under  a  fixed-price  contract,  the 
contractor  must  produce  the  required  items  or  perform  the  specific 
service  for  the  fixed  price  (or  within  the  ceiling  price  of  an  incentive 
contract)  or  be  subject  to  the  penalties  provided  for  in  a  default 
clause.  There  are  various  types  of  fixed-price  contracts  -  firm  fixed 
price  (FFP),  fixed  price  with  economic  adjustment  (FPEA),  fixed  price 
incentive  fee  (FPIF),  and  fixed  price  incentive  -  successive  targets 
(FPIS),  to  name  a  few.  Under  a  cost  reimbursement  contract,  the  product 
is  not  paid  for  on  the  basis  of  an  invoice  price;  rather  the  Government 
pays  the  contractor's  cost  for  material  and  labor  and  a  portion  of  his 
overhead  cost  in  accordance  with  appropriate  clauses  in  the  contract. 
The  principal  cost-type  contracts  include  cost,  cost  plus  fixed  fee 
(CPFF),  cost  plus  incentive  fee  (CPIF),  and  cost  plus  award  fee  (CPAF). 

Under  a  cost-type  contract,  the  contractor  agrees  to  use  his  best 
efforts  to  complete  the  contract  within  the  estimated  amount  provided  in 
the  contract.  However,  he  has  no  obligation  when,  despite  his  best 
efforts,  the  material  or  service  contracted  for  is  not  fully  provided  at 
the  time  he  expends  the  funds  in  the  contract.  The  contracting  officer 
may  provide  additional  funds  to  defray  the  cost  of  completing  the 
task(s)  delineated  in  the  contract. 

Clearly  the  cost  reimbursement  contract  has  the  potential  for  abuse 
if  the  contractor  is  permitted  to  spend  the  money  without  appropriate 
government  controls.  The  PM  must  have  the  manpower  resources  at  his 
disposal  to  effectively  monitor  contract  performance.  Despite  this,  the 
cost  reimbursement  contract  is  frequently  used  since  in  certain  situa¬ 
tions  it  is  unrealistic  to  employ  a  fixed-price  contract.  A  variety  of 
factors  (e.g.,  changing  reauirement,  unforeseen  technical  problems)  may 
affect  the  ultimate  cost  of  completion.  A  contractor  should  be  compen¬ 
sated  for  his  a’lowable  expenses,  and  it  is  both  unfair  and  unproductive 
to  throw  1 00%  of  the  cost  liaoility  on  the  contractor  when  it  is  not 
possible  to  determine  an  accur-ete  price  at  the  outset  of  the  contract. 

The  PM  and  contracting  officer  should  carefully  choose  the  type  of 
contracts  to  be  used  in  each  phase  of  the  acquisition  process.  Some 
members  of  the  contracting  corimunity  feel  that  during  the  Concept  Explo¬ 
ration  Phase,  when  the  risk  shared  by  the  government  and  contractor  is 
approximately  equal  and  the  actual  eno  product  has  not  been  specifically 
defined,  a  cost-reimbursement  contract  such  as  CPFF  is  most  suitable. 
Then,  as  the  risk  to  the  contractor  diminishes  and  the  product  becomes 
better  defined,  the  contract  type  can  be  shifted  to  CPAF  or  CPIF,  and 
ultimately  to  a  fixed-price  contract  (e.c.,  FPIF)  during  early  produc¬ 
tion.  The  relative  degree  of  risk  assumed  by  the  government  and  the 
contractor  as  a  function  of  the  type  of  contract  is  shown  in  Figure  4-7. 
(FPR  is  fixed-price  redetermination). 
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FIGURE  4-7.  Degree  of  Risk  as  a  Function  of  Contract  Type. 


The  more  generally  held  opinion,  however,  is  that  the  fixed-price 
type  of  contract  is  appropriate  for  use  during  the  Concept  Exploration 
Phase  because  such  a  contract  provides  the  only  means  of  putting  the 
contractors  in  a  truly  competitive  posture.  The  products  to  be  deliver¬ 
ed  under  the  Concept  Exploration  Phase  contracts  are  quite  clearly 
established.  They  are  defined  by  the  concept  proposers  themselves  in 
response  to  a  Request  for  Quotation  (RFQ)  featuring  the  defined  opera¬ 
tional  need.  The  end  product  being  contracted  for  is  a  proposal  for,  or 
a  disclosure  of,  a  proposed  system  to  meet  the  defined  operational  need. 

While  the  intent  of  the  contracting  effort  during  concept  explora¬ 
tion  is  to  maximize  the  competitive  exploration  of  alternative  concepts, 
the  dollar  amount  of  each  contract  should  be  sufficient  to  pay  for  the 
work  requested.  Contractors  should  not  be  expected  to  utilize  their  own 
funds  to  "buy  in".  The  desire  to  explore  as  many  concepts  as  possible 
must  be  tempered  by  the  necessity  of  funding  each  exploratory  effort  at 
an  adequate  level.  Parallel  short-term  contracts  provide  a  means  for 
compromising  between  the  number  of  concepts  to  be  explored  and  the  level 
of  funding  for  each.  A  large  number  of  concepts  can  be  funded  initially 
and,  by  reducing  the  number  of  contractors  remaining  after  each  short¬ 
term  segment,  the  total  expenditure  may  be  kept  within  the  established 
limits. 

Contract  cost,  although  it  is  an  important  consideration,  should 
not  be  the  overriding  consideration  in  this  phase  or  in  the  Demonstra¬ 
tion  and  Validation  (D&V)  Phase.  The  project's  overall  cost  objective 
is  the  minimization  of  LCC.  A  bit  more  money  spent  in  these  early 
phases  may  reduce  costs  significantly  in  later,  more  expensive  phases. 


During  the  D&V  Phase,  the  FFP  contract  may  be  the  best  choice. 
While  the  potential  uncertainties  are  greater  in  this  phase  than  the 
preceding  one,  and  thus  could  conceivably  warrant  a  cost  reimbursement 
type  of  contract,  if  this  phase  is  to  be  characterized  by  a  continuing 
high  level  of  competition,  the  contracts  should  continue  to  be  of  the 
fixed-price  type.  As  in  the  previous  phase,  the  dollar  amounts  of  a 
contract  in  D&V  Phase  should  represent  the  true  cost  of  the  work  which 
the  contractor  proposes  to  perform,  plus  a  reasonable  profit,  rather 
than  a  "buy  in"  value  which  relies  upon  substantial  contractor  invest¬ 
ment  which  he  hopes  to  recover  later. 

One  of  the  varieties  of  the  cost  reimbursement  contract  should  be 
used  for  the  FSD  Phase.  The  reason  for  this  is  that  usually  the  actual 
cost  to  resolve  the  remaining  technical  uncertainties  can  only  be  esti¬ 
mated  grossly  at  the  outset  of  the  phase.  The  government  must  have  the 
flexibility  to  make  the  decisions  required  to  achieve  the  best  cost- 
performance-  schedule  compromises  during  the  phase. 

Use  of  the  CPAF  contract  in  the  FSD  Phase  should  be  actively  con¬ 
sidered  by  the  PM.  In  this  type  of  contract,  the  fee  is  determined  by  a 
total  evaluation  of  the  product/system  and  contractor  performance  at 
pre-determined  intervals  in  the  course  of  the  contract,  or  at  contract 
completion.  The  CP1F  contract,  by  contrast,  has  the  fee  determined 
according  to  a  negotiated  formula,  and  is  considered  a  viable  instrument 
whenever  critical  contract  requirements  can  be  quantified  and  contract 
performance  against  these  requirements  can  be  accurately  measured.  The 
CPFF  contract  is  useful  in  situations  in  which  the  total  cost  of  devel¬ 
opment  at  any  given  time  is  reasonably  well  known  but  changes  in  scope 
are  anticipated.  The  CPFF  is  not  recommended  for  the  major  equipment 
development  contract.  7 

It  is  possible  that  the  pilot-production  subphase  of  FSD  could  be 
more  effectively  executed  under  a  fixed-price  contract.  The  decision  of 
whether  to  switch  contract  types  should  be  made  on  the  basis  of  maturity 
of  system  design  and  documentation  and  on  the  PM's  judgment  as  to  whet¬ 
her  any  "engineering  changes"  to  the  design  (normally  a  way  of  life 
under  any  production  contract)  can  be  handled  better  in  a  fixed-price  or 
cost-reimbursement  environment.  The  PM  should  remember  that  the  fixed- 
price  type  of  contract  at  this  juncture  tends  to  inhibit  that  all- 
important  stage  in  the  design  evolution  process  during  which  the  design 
is  accommodated  to  the  production  processes  and  procedures.  Contracts 
for  production  for  service  use  and  service  inventory  should  normally  be 
FFP.  The  use  of  multi-year  contracts  should  also  De  considered  for 
those  programs  where  it  would  provide  significant  cost  savings. 

The  contract  is  one  of  the  PM's  essential  tools.  He  should  there¬ 
fore  build  a  strong  justification  for  the  type  of  contract  he  desires 
for  the  task  at  hand.  As  a  rule,  the  contracting  officer  will  tend  to 
favor  the  fixed-price  type  contract  because  it  is  generally  easier  to 
administer  than  the  cost-reimbursement  type  and,  theoretically,  places 
the  cost  liability  on  the  contractor.  The  PM  must  bear  in  mind  that  the 
contracting  officer  operates  within  a  framework  of  some  4,000  pages  of 
regulations,  clearances,  approvals,  etc.  Changes  in  a  contract  require 
a  great  deal  of  time  and  effort  on  his  part.  Re-negotiating  a  cost- 
reimbursement.  type  of  contract  is  not  a  simple  process,  a  fact  that  the 
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PM  should  take  into  consideration  in  determining  the  degree  of  project- 
ed-cost-curve  slippage  that  will  be  permitted  before  he  calls  for  re¬ 
negotiation.  In  the  final  analysis  it  is  the  PM  alone  who  has  an 
overview  of  the  entire  program.  It  is  he  and  not  the  contracting  offi¬ 
cer  who  will  be  most  affected  by  program  delays,  cost  overruns,  contract 
litigation,  and  similar  problems  that  arise  frdm  legally  sound  but 
tactically  ur.v/ise  contract  decisions. 


Contract  Requirements  Establishment 

Procurement  Request .  The  most  vital  document  that  supports  the 
communication  between  the  PM  and  the  contracting  officer  is  the  procure¬ 
ment  request.  The  purpose  of  the  procurement  request  is  to  provide 
Information  that  (1)  describes  the  required  supplies  requirement  or 
services  clearly  and  completely  so  that  the  contracting  officer  may 
obtain  acceptable  offers  for  performance  of  the  proposed  procurement, 
and  (2)  supports  any  contractual  recommendations  it  may  contain  (such  as 
a  proposal  to  limit  sources).  For  example,  the  procurement  request 
documentation  serves  as  a  basis  for  determining  the  method  of  procure¬ 
ment  and  for  obtaining  business  and  other  clearances  required  by  appli¬ 
cable  regulations.  The  procurement  request  also  becomes  part  of  the 
permanent  record  of  the  procurement  and  thus  it  serves  to  support  the 
government's  position  in  any  hearing  or  inquiry  conducted  in  connection 
with  its  handling.  Accordingly,  the  PM  must  ensure  that  the  procurement 
request  is  carefully  prepared  and  submitted  to  the  contracting  officer 
in  a  timely  manner. 

The  documents  defining  the  effort  to  be  accomplished  under  the 
contract  must  be  precise  and  complete.  The  contracting  office  will 
provide  the  best  counsel  for  much  of  the  input,  including  standard 
clauses  and  the  like.  The  inputs  will  not  be  discussed  here  except  to 
note  that,  it  is  imperative  to  assure  that  appropriate  technical  members 
of  the  procurement  team  be  afforded,  by  contract  provision,  ready  access 
to  the  contractor's  plant,  personnel,  in-process  effort,  and  pertinent 
records.  There  are  two  areas  in  which  it  is  essential  that  the  techni¬ 
cal  side  of  the  procurement  team  have  the  overriding  input.  These  areas 
relate  to  the  Statement  of  Work  (SOW)  and  to  data  requirements. 

Statement  of  Work  (SOW).  The  SOW  is  used  by  the  PM  and  his  staff 
to  define  the  non-specification  work  effort  required  from  contractors 
and  Naval  support  activities  in  support  of  the  Navy  programs.  The  SOW 
writers  must  be  familiar  with  the  policy  concepts  of  NAVMATINST  4120.108 
to  ensure  that  they  have  taken  every  step  toward  (1)  structuring  their 
technical  requirements  to  meet  minimal  needs,  and  (2)  holding  the  cost 
drivers  to  minimal  levels  by  tailoring  referenced  military  specifica¬ 
tions  and  military  standards  to  the  exactness  of  those  needs  and  risk 
thresholds  within  the  SOW.  MIL-HDBK  245A  (Navy)  provides  information 
necessary  for  the  preparation  of  a  SOW  and  should  be  carefully  read  by 
the  preparer  of  the  SOW  and  by  the  PM  before  reviewing  the  SOW. 

After  the  contract  has  been  awarded,  the  SOW  becomes  the  standard 
for  measuring  the  contractor's  effectiveness.  As  the  effort  progresses, 
the  Navy  and  the  contractor  will  constantly  refer  to  the  SOW  to  define 
and  clarify  their  responsibilities  and  obligations.  When  a  question 
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arises  concerning  an  apparent  increase  in  the  scope  of  non-specification 
work  to  be  performed,  the  SOW  is  the  governing  document  which  must  be 
used  to  resolve  the  matter.  Language  in  the  SOW  defining  the  scope  of 
limits  of  the  contractor's  effort  is  of  critical  importance  at  this 
time.  If  the  SOW  requirements  are  poorly  stated,  it  will  be  difficult 
to  determine  if  or  when  there  has  been  an  increase  in  scope,  with  the 
result  that  effective  negotiations  on  cost  and  schedule  will  be  impair¬ 
ed,  if  not  impossible. 


Data  Requirements.  A  contract  which  requires  any  sort  of  data  as  a 
deliverable  item  must  include  a  Contract  Data  Requirements  List  (CDRL), 
DD  Form  1423.  This  list  must  state  all  data  that  the  contractor  is  to 
deliver.  This  might  include  design  drawings  and  specifications,  test 
reports,  manuals,  analyses,  status  reports,  cost/schedule  reports  and 
the  like.  For  many  of  these  items,  a  standard  DOD-approved  Data  Item 
Description  (DID)  is  available  and  must  be  used,  with  appropriate  tail¬ 
oring. 

A  balance  has  to  be  achieved  between  ensuring  that  the  data  requir¬ 
ed  for  administrative,  statutory  and  programmatic  needs  are  obtained  and 
the  elimination  of  unnecessary  and  redundant  reports.  The  CDRL  estab¬ 
lishes  a  burden  on  both  the  contractor  and  the  government.  Data  and 
reports  cost  money  to  obtain  and  prepare.  Consideration  of  specific 
program/contract  requirements  should  be  considered  in  establishing  the 
frequency,  detail  level,  and  distribution  of  reports.  Contractual  re¬ 
quirements  for  data  must  be  identified  in  the  CDRL.  The  SOW  and  provi¬ 
sions/cl  auses  within  the  contract  should  not  spell  out  data  requirements 
that  are  not  in  the  CDRL  or  it  may  result  in  data  being  produced  and 
paid  for  without  the  PM'S  knowledge  or  without  any  programmatic  require¬ 
ment.  Such  data  requirements  also  open  up  the  possibility  of  a  dispute, 
since  the  contractor  does  not  have  to  provide  data  not  called  out  by  the 
CDRL.  Preparation  of  the  CDRL  needs  the  personal  attention  of  the  PM. 


Source  Solicitation 

The  PM  will  be  guided  by  DODD  4105.62,  NAVMATINST  4200.49,  and  his 
contracting  officer  for  procedural  direction  in  the  formal,  structured, 
source  solicitation,  and  proposal  evaluation  process.  The  following 
paragraphs  provide  only  background  information  oriented  to  the  PM's  role 
in  the  process.  The  simplest  form  of  a  Request  for  Proposal  (RFP), 
although  seldom  used,  is  the  requirement  document  and  a  cover  letter. 

A  clear  understanding  should  be  reached  between  the  respondents  and 
the  Navy  with  respect  to  the  Navy's  needs.  Industry,  Navy  laboratories/ 
centers,  and  other  institutions  should  be  encouraged  to  comment  on  and 
provide  input  to,  a  draft  of  the  solicitation.  These  comments  and 
inputs  should  be  requested  industry-wide  and  from  all  appropriate  insti¬ 
tutions.  Requests  should  not  be  confined  to  one  or  two  favored  contrac¬ 
tors. 


The  PM  should  be  aware  that  it  is  "good"  industry  practice  for  a 
contractor  to  try  to  influence  the  solicitation  so  that  it  stresses  his 
strengths.  This  should  be  resisted.  The  PM  must,  with  appropriate 
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assistance  and  approval,  establish  policies  and  procedures  that  will 
make  available  to  competitors  the  information  developed  by  Navy  labora¬ 
tories  and  other  support  activities  along  with  any  other  essential, 
government-owned  information.  Such  policies  and  procedures  should  en¬ 
sure  that  the  competitors  are  free  to  propose  solutions  of  their  own 
devising,  which  may  or  may  not  use  the  government-developed  solutions  or 
approaches. 


Solicitation 

0MB  Circular  A-109  and  Navy  acquisition  practice  permit  and  encou¬ 
rage  the  use  of  a  single  solicitation  for  the  entire  acquisition  pro¬ 
cess,  from  disclosures  of  alternative  concepts  through  FSD  and  initial 
production.  It  is,  however,  frequently  useful  to  issue  a  separate  or 
supplementary  solicitation  for  each  phase  effort  at  the  time  of  or  just 
prior  to  its  initiation.  These  solicitations  should  request  proposals 
near  the  end  of  each  phase  from  all  active  contractors  who  are  still  in 
the  competition.  Negotiations  concerning  these  proposals  should  be 
undertaken  and  carried  forward  while  the  contractors  are  still  in  com¬ 
petitive  status. 

The  contracts  awarded  for  the  D&V  Phase  effort  should  include  such 
output  requirements  as  a  complete  set  of  proposed  allocated  baseline 
configuration  specifications  for  the  individually  identified  configura¬ 
tion  items,  and  a  proposal  for  the  FSD  Phase  and  initial  production 
effort . 

If  the  contractors'  outputs  during  the  Concept  Exploration  Phase 
did  not  contain  sufficient  detail  to  permit  the  preparation  of  a  compre¬ 
hensive  Statement  of  Work  (SOW),  the  PM  may  request  additional  material 
from  the  contractors.  Evaluation  criteria  and  an  evaluation  methodology 
can  then  be  devised,  and  the  data  and  documentation  requirements  and  the 
tasks  to  be  performed  can  be  defined  prior  to  the  issuance  of  contracts. 
Some  areas  that  should  be  specifically  treated  In  the  solicitation  for 
the  D&V  Phase  are  discussed  in  the  following  paragraphs. 


Use  Environment.  A  system  that  will  meet  the  Navy's  need  must  be 
capable  of  being  transported  from  the  place  of  manufacture,  in  some 
cases  stored,  and  ultimately  performing  in  the  use  environment.  This 
environment  may  include  friendly  and  hostile  electromagnetic  radiation, 
countermeasures,  maneuvers,  friendly  and  enemy  weapon  systems,  and  ad¬ 
verse  weather.  Based  on  the  mission  profile  (NAVMATINST  3000. 1 A)  pre¬ 
pared  during  the  Concept  Exploration  and  D&V  Phases,  the  PM  should  have 
an  Environmental  Design  Criteria  Document  (EDCD)  prepared  and  incorpo¬ 
rated  as  part  of  the  development  specifications.  He  should  also  spell 
out  what  demonstrations  are  necessary  to  show  that  a  contractor's  con¬ 
cept  has  the  potential  for  being  developed  into  a  system  that  will 
function  effectively  in  the  use  environment. 


Cost  Estimating  and  Data  Requirements.  The  cost  estimating  and 
data  requirements  called  for  in  the  solicitation  should  be  carefully 
chosen  by  the  PM.  He  should  require  the  contractors'  data  and  the 
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models  that  they  used  be  made  available  to  the  Navy.  This  will  assist 
the  Navy  in  performing  independent  design-to-cost  and  LCC  estimates  of 
all  the  competitive  systems,  and  trade-off  studies  of  LCC,  schedule,  and 
performance.  It  may  help  prevent  contractors  from  "buying-in":  submit¬ 
ting  optimistic  and  unrealistic  cost  estimates  for  full-scale  develop¬ 
ment  (FSD],  production,  and  operation.  The  PM  must  recognize  the  impli¬ 
cations  of  a  "buy-in"  and  assume  the  lead  role  in  preventing  it  or 
altering  the  acquisition  strategy  accordingly  to  allow  the  greater 
degree  of  control  required.  The  PM  should  identify  the  government 
activity  responsible  for  storing,  retrieving,  and  processing  the  date 
and  make  this  information  known  *0  the  program  organization  and  contrac¬ 
tors  (see  DODI  7000.11  and  NAVMAT  Pub.  No.  5241).  However,  only  that 
data  which  is  really  needed  should  be  required  from  the  contractors  as 
described  in  NAVMATINST  5000.15. 


System  Specification  and  Documentation  Requirement.  The  system 
specification  is  used  to  state  technical  and  mission  requirements  for 
the  system,  allocate  requirements  to  functional  areas,  and  define  inter¬ 
faces  between  functional  areas.  Requirements  for  the  system  specifica¬ 
tions  and  other  documentation  must  be  set  forth  in  detail  in  the  solici¬ 
tation  and  SOW. 

The  system  specifications  proposed  by  the  contractors  at  the  end  of 
the  Concept  Exploration  Phase  will  normally  be  the  basis  for  the  func¬ 
tional  baseline  configuration  set  out  in  the  solicitation.  The  PM  must 
ensure  that  the  functional  baseline  configuration  accurately  reflects 
the  needs  of  the  Navy.  However,  it  should  be  defined  broadly,  thus 
allowing  the  contractor  the  necessary  latitude  to  use  innovative  techni¬ 
cal  and  production  approaches. 

The  system  specification  developed  by  each  contractor  during  the 
D&V  Phase  will  constitute  the  allocated  baseline  configuration  of  the 
system  that  he  proposes  to  develop  during  the  F5D  Phase.  This  baseline 
establishes  the  performance  thresholds  which  will  be  incorporated  into 
the  milestone  review  documents  (MRD)  and  submitted  for  approval  at 
Milestone  II.  Typical  considerations  that  should  be  addressed  are  shown 
in  Figure  4-8. 

The  proposals  requested  should  include  the  proposed  system  specifi¬ 
cation  for  the  allocated  baseline  configuration  as  well  as  the  specifi¬ 
cation  for  performance,  interfaces,  and  technical  requirements  of  in¬ 
dividually  identified  configuration  items.  If  it  is  possible  that 
production  will  be  competed,  the  cost  of  proprietary  and  other  data 
rights  and  cost  of  developing  a  Level  III  documentation  package  should 
also  be  included  in  the  bid  package  while  the  maximum  amount  of  competi¬ 
tion  prevails.  Estimated  procurement  costs  should  be  an  important 
criteria  for  selection  of  the  follow-on  contractor.  If  possible,  the 
competition  for  FSD  should  also  result  in  production  options  with  com¬ 
petitively  determined  ceiling  price. 


Competition 


One  of  the  most  important  considerations  a  PM  will  address  is  the 
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FIGURE  4-8.  Solicitation  Documentation. 


task  of  "obtaining  end  sustaining  competition".  DODD  5000.1  states  that 
"effective  design  and  price  competition  for  defense  systems  shall  be 
obtained  to  the  maximum  practical  extent  to  ensure  that  defense  systems 
are  cost-effective  and  responsive  to  mission  needs."  The  basic  concept 
of  competition  is  simply  that  a  competitive  environment  influences  both 
individuals  and  organizations  to  excel.  This  concept  is  the  very  foun¬ 
dation  for  our  free  market  economic  system.  The  Competition  in  Contract¬ 
ing  Act  of  1984  (PL  98-369)  as  well  as  FAR  7.000  emphasize  that  full  and 
open  competition  is  considered  standard;  and  that  sole  source  procure¬ 
ments  require  full  justification  and  authorization  of  the  agency  head. 
Competition  will  almost  always  be  worth  the  money  spent  to  generate  it. 
There  are  two  very  substantial  reasons  to  try  and  obtain  the  maximum 
degree  of  competition:  (1)  to  develop  the  concept  that  best  meets  the 
mission  need  at  lowest  L.CC  and  (2)  to  obtain  that  system  at  the  lowest 
production  costs.  The  first  goal  is  achieved  by  competition  in  the 
Concept  Exploration  and  D&V  Phases  and  the  latter  goal  in  the  FSD  and 
Production  Phases.  The  ground  work  for  competition  in  production  needs 
to  be  accomplished  during  the  development  phases. 
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In  order  to  ensure  that  the  Navy  reaps  the  benefits  of  competition 
in  new  programs,  procedures  have  been  initiated  by  which  each  program  is 
given  an  independent  assessment  as  to  the  benefits  of  introducing  com¬ 
petition  at  the  time  of  its  milestone  review.  In  addition,  the  Navy  has 
established  the  flag  level  position  of  Competition  Advocate  General  {see 
Section  3)  [MAT  09P  and  dual  hatted  under  ASN(S&L)j  with  the  objective 
of  increasing  competition  in  all  types  of  procurement.  Also  Competition 
Advocates  have  been  appointed  at  all  Navy  buying  activities  with 
procurement  authority  over  $25,000  and  at  many  field  activities  which 
generate  more  than  $1  million  in  annual  procurement  requirements. 

While  a  contractor  may  have  a  number  of  reasons  for  bidding  on  a 
program  including  entering  new  fields  or  maintaining  a  staff  during 
"lean  periods",  the  most  compelling  motivation  of  the  contractor  is  to 
maximize  profit.  This  is  often  in  conflict  with  the  PM's  motivation  to 
get  the  best  system  for  the  least  money.  Competition  is  far  and  away 
the  best  device  the  Government  has  at  its  disposal  to  ensure  a  reason¬ 
able  balance  between  these  two  opposing  ends. 

During  the  Concept  Exploration  and  D&V  Phases,  the  thrust  of  compe¬ 
tition  is  to  conceive  and  clarify  the  concepts  most  likely  to  meet  the 
mission  need  within  the  constraints  of  time,  cost,  and  interfacing 
requirements.  After  these  phases  are  completed;  competition  normally 
ceases  unless  more  than  one  competitor  is  carried  into  FSD  -  a  situation 
that  rarely  happens.  More  typically,  the  efforts  of  the  winner  of  the 
D&V  Phase  competition  are  shifted  to  the  development  of  the  selected 
concept.  Not  until  the  system  has  been  fully  developed  and  approved  for 
service  use,  and  volume  production  for  service  use  has  been  started,  is 
it  possible  to  reinstitute  competition.  The  ground  work  for  competition 
in  production  needs  to  be  done  during  the  development  phases;  it  cannot 
be  readily  introduced  as  an  afterthought. 

A  current  Navy  acquisition  program,  the  Advanced  Self- Protection 
Jammer  (ASPJ),  is  using  the  interesting  concept  of  tandem  contractors 
during  the  FSD  Phase.  This  program's  acquisition  strategy  called  for 
the  pairing  of  contractors  into  teams,  each  team  competing  against  the 
others.  After  progressive  narrowing  of  the  field  during  the  first  two 
phases,  the  winning  team  is  jointly  developing  the  system  up  to  the 
commencement  of  the  Production  and  Deployment  Phase,  when  the  contrac¬ 
tors  will  submit  competitive  proposals  for  the  first  volume  production 
buy.  The  winning  contractor  (the  leader)  will  be  awarded  70%  of  the 
first  production  buy  and  the  other  contractor  (the  follower),  30%,  with 
an  option  reserved  to  the  Government  to  reverse  these  percentages  after 
competition  for  subsequent  buys. 

Competition  during  the  production  phase  can  have  a  startling  effect 
on  cost  reduction.  In  one  instance  involving  the  guidance  and  control 
group  of  a  guided  missile,  the  development  contractor  proposed  a  unit 
production  cost  of  $20,000.  This  was  judged  to  be  unsatisfactory  and 
the  buy  was  opened  to  competition.  The  unit  production  cost  immediately 
dropped  to  $4,000.  Even  including  the  cost  of  establishing  a  production 
line  at  an  alternative  source,  the  projected  savings  for  the  inventory 
then  visualized  was  on  the  order  of  $200  million,  much  more  than  the 
entire  cost  of  the  development  program.  The  PM  whose  program  involves 
high  volume  production  of  the  system  or  any  of  its  parts  should  so 
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structure  his  acquisition  strategy  that  competition  during  the  Produc¬ 
tion  and  Deployment  Phase  is  not  precluded.  The  developing  contractor 
may  attempt  to  justify  his  use  of  all  funds  available  for  production 
(e.g.,  by  planning  large  investments  in  production  tooling).  It  is 
essential  that  the  PM  protect  his  funds  and  not  permit  the  developing 
contractor  to  set  up  entry  barriers  for  second-source  production.  DSMC 
has  available  a  "Competition  Handbook,  Reestablishing  Competitive  Pro¬ 
duction  Sources  -  August  1981". 

Concept  Exploration  and  D&V  Phases.  Within  the  limits  of  manage¬ 
ability,  the  PM  should  solicit  inputs  from  the  greatest  possible  number 
of  qualified  firms.  Quality,  rather  than  quantity,  is  the  critical 
factor  in  this  process  and  other  should  be  concerted  effort  to  identify 
and  solicit  those  firms  that  have  the  highest  likelihood  of  submitting 
viable  concepts.  After  the  best  proposals  have  been  selected  for  con¬ 
cept  exploration,  the  inevitable  narrowing  of  the  field  at  Milestone  I 
maintains  a  strong  competitive  atmosphere  which  will  continue  to  moti¬ 
vate  the  contractors  throughout  the  D&V  Phase. 

The  PM  should  exercise  care  in  determining  the  amount  of  funds  to 
be  allocated  to  each  concept  formulation  contract.  A  few  reasonably 
funded  contracts  will  have  greater  value  than  many  inadequately  funded 
contracts  for  which  contractor  funding  augmentation  is  required  to 
produce  a  reasonable  product. 

Final  Concept  Exploration  Phase  reports  by  the  competitors  should 
include  the  information  required  for  inclusion  in  the  Milestone  I  review 
documentation,  proposed  statements  of  work,  and  proposals  for  conducting 
validation  effort.  ILS,  production  procedures,  required  system  inter¬ 
faces,  system  safety,  human  factors,  and  other  areas  related  to  the  end 
use  of  the  system  concept  should  be  addressed,  although  in-depth  studies 
should  not  be  expected  at  this  time. 

This  should  include  criteria  for  D&V  and  identification  of  high 
risk  areas.  When  areas  of  high  technical  risk  become  apparent,  the  use 
of  appropriate  in-house  R&D  laboratories/  centers  to  explore  means, 
other  than  those  taken  by  the  contractor,  for  circumventing  or  minimiz¬ 
ing  such  risks  is  encouraged.  The  PM  may  also  want  to  consider  the  use 
of  these  facilities  when  he  establishes  procedures  for  the  independent 
estimating  of  system  LCC.  The  cost,  schedule  and  performance  estimates 
used  to  support  Milestone  I  must  be  realistic  to  avoid  large  perturba¬ 
tions  later  at  Milestone  II. 

The  PM  should  attempt  throughout  these  phases  to  acquire  all  neces¬ 
sary  rights  to  the  systems  being  developed,  and  he  should  prohibit 
contractors  from  incorporating  proprietary  items  and  processes  into 
their  systems.  This  will  facilitate  competitive  procurement  in  the 
Production  and  Deployment  Phase  if  such  is  desired.  Another  reason  for 
seeking  to  acquire  rights  to  the  systems  is  that  the  system  selected  for 
FSD  may  benefit  from  a  synthesis  of  technology  from  competing  systems, 
although  industry  will  typically  deny  the  need  for  this  *  synthesis, 
arguing  that  FSD  should  go  to  the  "best"  overall  contract  solution.  Tne 
issue  of  whether,  and  how,  to  secure  government  ownership  of  proprietary 
material  must  be  addressed  by  the  PM  prior  to  source  selection.  The 
provisions  by  which  this  ownership  will  be  obtained  must  be  clearly 
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defined  in  each  contract. 


FSD  Phase.  It  is  difficult  to  maintain  competition  as  a  driving 
force  for  contractor  performance  in  the  FSD  Phase  unless  the  acquisition 
strategy  dictates  that  two  competing  concepts  will  be  carried  into  FSD 
or  the  PM  pursues  an  acquisition  strategy  similar  to  that  followed  in 
the  ASPJ  program  noted  above.  More  typically  competition  ceases  at  the 
conclusion  of  the  D&V  Phase,  except  possibly  at  the  subsystem  or  compo¬ 
nent  level.  However,  if  successful  competition  for  procurement  or  re¬ 
procurement  is  desired  in  the  Production  and  Deployment  Phase,  early 
planning  which  is  given  substance  and  visibility  in  the  acquisition 
strategy  must  be  implemented  in  the  FSD  Phase.  Successful  competition 
demands  that  the  product  baseline  configuration,  as  revealed  by  the 
specifications,  drawings,  and  other  documents,  be  carefully  controlled 
and  kept  current  and  free  of  gimmicks  that  might  render  them  incompa¬ 
tible  with  industrial  firms  other  than  the  development  contractor.  The 
development  contractor  must  not  be  permitted  to  develop  designs  that 
require  special  tooling  setups  available  only  to  him,  or  to  include  his 
proprietary  devices  or  processes  that  will  not  be  made  available  to  the 
general  industrial  community.  Such  practices  can  be  averted  if  the  PM 
and  his  technical  team  conduct  in-process  reviews  of  the  documentation 
package  as  it  develops  and  see  that  the  Government  takes  physical  custo¬ 
dy  and  establishes  configuration  control  at  the  time  of  release  to  pilot 
production  or  when  formal  technical  evaluation  (TECHEVAL)  is  initiated. 

Production  Competition  Principals  and  Cost  Considerations.  OSD  has 
established  the  following  principals  and  cost  considerations  to  be 
observed  in  assessing  merits  of  production  phase  competition  for  major 
system  CACAT  I)  acquisition.  They  serve  the  as  useful  guidelines  for 
all  Navy  acquisitions.  They  are  as  follows: 

Production  Competition  Principals 

o  There  is  a  firm  inventory  requirement  for  the  item 
sufficiently  large  to  amortize  facilities,  tooling  and 
qualification  costs  of  multiple  producers. 

o  The  requirement  has  an  urgent  or  high  enough  priority  so  that 
funds  will  be  programmed  by  the  service  and  eventually  appro¬ 
priated  by  the  Congress  to  buy  the  item  in  annual  quantities 
that  will  yield  economical  production  rates  for  two  producers. 

o  The  cost  benefit  analysis  clearly  shows  that  substantial  sav¬ 
ings  can  be  obtained  through  competition  driving  down  the 
cost.  The  analysis  should  be  conservative,  e.g.,  show  counter 
to  savings  of  loss  of  learning  due  to  split  buy,  and  not 
project  a  premature  competition  buyout. 

o  There  is  keen  interest  by  capable  competitive  firms  wanting  to 
participate. 

o  Proceeding  with  establishing  the  multiple  sources  will  not  be 
defeated  by  problems  with  proprietary  information,  acquiring 
re-procurement  data  or  assumption  of  government  configuration 
control . 
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o  Program  time  and  resources  are,  or  can  be  made  available,  to 
establish  and  qualify  multiple  sources  and  competition  will  be 
given  sufficient  program  priority  that  such  funds  will  not  be 
diverted. 

o  Industrial  base  considerations  complement  establishing  multi¬ 
ple  sources. 

o  The  competitive  environment  can  be  sustained  given  the  pro¬ 
grammed  quantities  and  corresponding  rates  of  production. 

o  The  operational  and  logistical  needs  of  the  mission  can  accom¬ 
modate  introduction  of  equipment  from  multiple  sources. 

Cost  Considerations 

o  Estimate  net  investment  required  to  establish  multiple  source 
production  capability. 

o  Compare  recurring  costs  from  a  single  source  versus  costs  from 
two  or  more  contractors  in  competition. 

o  Compare  non-recurring  costs  in  a  single  source  environment 
versus  a  competitive  environment, 

o  Discount  results  (i.e.,  compare  savings  in  outyears  to  upfront 
investment  in  present  value  terms) 

Production  and  Deployment  Phase.  Competition  should  normally  not 
be  renewed  unti 1  the  production  baseline  configuration  and  the  inspec¬ 
tion  and  acceptance  procedures  have  been  fully  evolved  and  demonstrated 
to  be  complete,  stable,  and  in  all  other  respects  adequate  to  enable 
production  at  the  desired  rate  by  a  commercial  firm  other  than  the 
development  contractor.  No  disclosure  to  production  should  be  consider¬ 
ed  to  have  achieved  that  condition  until  the  three  subphases  of  the  FSD 
effort  have  been  completed  and  volume  production  achieved  by  the  devel¬ 
opment  contractor  himself  in  accordance  with  the  production  disclosure. 
However,  occasionally,  as  with  the  Sparrow  AIM  7F,  competition  was 
introduced  prior  to  the  production  by  the  developer  of  a  satisfactory 
reliable  round.  Indeed,  one  of  the  purposes  of  this  competition  was  to 
improve  system  reliability  and  performance. 

In  the  case  of  sophisticated  guided  weapons  which  must  be  produced 
in  strict  accordance  with  a  detailed  and  rigorously  controlled  gov¬ 
ernment  design  disclosure  and  performance  specification,  initiation  of 
competition  prior  to  initial  volume  production  may  cause  severe  disrup¬ 
tion  in  the  program  time  schedule  and  increase  the  probability  of  intro¬ 
ducing  inferior  quality  products  into  the  service  inventory.  Such 
problems,  once  introduced,  tend  to  persist  and  eventually  jeopardize 
timely  realization  of  a  critical  initial  operational  capability  (IOC) 
and  achievement  of  the  project  inventory  objective  as  well.  They  may 
also  lay  the  foundation  for  contractor  claims  and  lengthy,  costly  liti¬ 
gation  which  the  government  seldom  wins. 
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Even  when  competition  is  reintroduced  at  the  proper  time,  it  must 
be  done  prudently.  Experience  has  repeatedly  shown  that  the  govern¬ 
ment's  interests  are  best  served  when  the  PM  takes  the  tine  and  incurs 
the  cost  necessary  to  assure  a  demonstrated  compatibility  between  any 
new  source  and  the  design  disclosure  before  that  source  is  allowed  to 
manufacture  articles  for  the  service  inventory.  In  cases  where  invento¬ 
ries  are  unacceptably  low  and  assured  deliveries  of  acceptable  hardware 
are  essential,  the  new  source  should  be  qualified  before  the  active 
source  is  allowed  to  go  inactive.  This  familiarization  is  best  accom¬ 
plished  through  the  careful  T&E  of  a  limited  quantity  "familiarization" 
buy  from  the  new  contractor  before  a  head-to-head,  winner-take-all , 
share-the-buy,  or  leader-follower  competition  is  undertaken. 

The  PM  should  realize  that  when  the  design  drawings,  processes, 
procedures,  and  other  documents  necessary  for  the  transfer  of  the  pro¬ 
duction  of  a  sophisticated  piece  of  hardware  are  duplicated  and  trans¬ 
ferred  from  one  contractor  to  another,  there  is  probably  more  knowledge 
and  understanding  of  how  to  produce  the  article  that  is  left  behind  in 
the  minds  and  hands  of  the  active  producer  than  is  contained  in  the 
transferred  material.  Learning  curves  in  production  programs  are  not 
idle  concepts.  They  are  facts  of  production  life  and,  as  such,  must  be 
reckoned  with. 


Contractor  Underbidding  (Overoptimism)* 

"At  the  outset  of  a  program,  our  DOD  bid  process  encourages  sub¬ 
stantial  contractor  overoptimism  in  technical  accomplishment,  in  sche¬ 
dule,  and  in  cost.  The  contractor  environment  is  one  of  competition  to 
win  the  support  of  the  evaluators  of  the  proposal;  thus  the  contractor 
very  much  caters  to  the  evaluator's  interests.  Most  major  requests  for 
proposals  are  evaluated  by  service  technologists  who  will  not  themselves 
have  a  role  in  implementing  the  program,  which  means  they  are  not  dom¬ 
inated  by  implementation  interests.  In  fact,  these  technologists  have 
little  experience  in  cost  control  or  production  implementation  and  so 
frequently  are  not  competent  to  judge  implementation  issues.  They  do, 
however,  have  a  high  interest  in  trying  to  exploit  in  operation  the  most 
taxing  technology.  The  technologists  can  see  only  the  merit  of  new 
techniques,  not  their  difficulty  -  and  they  are  the  judges. 

"In  the  main,  the  program  office  that  is  to  execute  the  work  is 
given  the  program  only  after  the  major  characteristics  of  schedule, 
technical  risk,  and  costs  have  been  decided  and  cast  in  concrete.  In 
practice,  they  cannot  reject  an  unrealistic  program.  In  fact,  seldom 
does  a  program  manager  have  a  chance  to  really  understand  the  quality  of 
his  going-in  position  before  he  is  bound,  contractually,  to  its  execu¬ 
tion. 


*  This  section  was  extracted  fro*  an  article  by  Or.  W.  B. 
LsSerg?  (foreer  industry  vice  president.  Technical  Director  of 
a  Navy  RCO  Center,  Assistant  Secretary  of  the  Air  Force  for 
FiCD,  and  Under  Secretary  of  Any)  that  appeared  in  Concepts 
(Vol.  5,  No.  1,  Winter  1982)  published  by  the  DSNC.  The  arti¬ 
cle  is  entitled  "Oefense  Acquisition:  A  Ga»e  of  liar's  Dice". 
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“The  contractor  proposal  is  most  usually  the  basis  for  all  execu¬ 
tion  planning,  even  though  'promising  the  moon'  is  known  to  be  the  key 
to  successful  contract  award.  Proposal  writing  in  the  last  few  years 
has  become  Liar's  Dice  in  its  Ultimate  embodiment.  There  is  no  disin¬ 
centive  to  writing  a  barely  credible  proposal  that  can  match  the  disin¬ 
centive  to  writing  a  conservative  proposal;  namely,  the  loss  of  the 
award . 


"Not  only  does  DOD  provide  no  disincentive  to  the  low-balling  of 
bids,  it  further  hurts  itself  by  not  including  in  its  long-term  esti¬ 
mates  the  cost  reserves  necessary  to  compensate  for  the  unrealistic 
bids. 


"The  Fallacy  of  Fixed  Price.  To  further  complicate  matters,  there 
is  the  erroneous  belief  on  the  part  of  the  acquisition  community  that 
R&D  procurement  with  fixed-price  initial  production  options  helps  im¬ 
prove  cost  credibility.  Nothing  could  be  further  from  the  truth.  If 
anything,  it  hurts  cost  realism.  These  fixed-price  procurements  do 
nothing  to  obtain  better  bids,  hut  do  much  to  deny  the  government  the 
cost  information  that  is  much  more  available  to  it  in  a  cost-reimburse¬ 
ment  environment. 

"A  contractor  today  is  asked  to  bid  fixed-price  in  competition  with 
another  vendor  on  development  and  up  to  10%  of  the  expected  long-term 
production.  Each  contractor  knows  that  if  he  can  win  the  first  competi¬ 
tive  b’d,  he  will  be  facilitated  by  the  government  or  assured  of  a 
contract  that  will  allow  him  write-off  f aci 1 itization,  that  he  will  have 
a  labor  bare  to  absorb  his  fixed  overhead,  that  he  will  be  able  to 
absorb  company-sponsored  future  development  work,  and  that  he  can  even¬ 
tually  make  a  profit.  He  knows  that  if  he  loses  he  will  be  unable  to  do 
any  of  these  things.  In  fact,  without  a  new  labo  oase,  he  may  spoil 
the  profitability  of  his  present  contracts.  The  ci  tractor  also  knows 
that  he  is  reasonably  safe  from  punitive  action.  He  knows  that  the 
Federal  Acquisition  Regulations  System  (FARS)  assure  him  that  he  will  be 
paid  real  costs  and  a  fair  fee  for  the  remaining  90%  of  the  production, 
which  by  then  will  no  longer  be  in  competition.  He  also  knows  that  in 
today's  application  of  tne  FARS  his  fee  on  the  non-competitive  90%  is 
not  determined  by  the  dimensions  of  the  exaggerations  he  may  have  told 
to  get  the  job  in  the  first  place. 

"In  light  of  all  these  considerations,  today's  contractor  inevitab¬ 
ly  explores  how  low  he  can  bid  on  the  competitive  10%  and  still  make  out 
on  the  fees,  overhead,  G&A,  and  benefits  of  the  non-competitive  90%. 

"The  only  real  disincentive  to  a  low-balling  bid  is  the  possibility 
of  problems  with  cash  flow  on  a  gross  underbid.  But  good,  strong  com¬ 
panies  (and  many  others  not  so  strong)  are  willing  in  this  kind  of 
competition  to  risk  quite  a  cash  flow  hit  if  the  benefits  can  be  expect¬ 
ed  to  be  great  enough.  This  situation  is  quite  unrealized  by  DOD  today. 

"Proposals  to  Prevent  Contractor  Underbidding  (Overoptimism) .  Make 
as  a  condition  of  al)  bids  down-selecting  to  a  single  proauction  con¬ 
tractor  that  fee  and  G&A  recovery  for  the  entire  contract  will  be  scaled 
to  how  well  downstream  production  costs  correspond  to  the  estimates 
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made  at  the  time  of  down-selection. 

'‘Make  as  a  condition  of  contracts  leading  to  production  that  full 
amortization  of  production  tooling  investment  be  guaranteed  or  that  the 
tooling  will,  if  desired,  be  bought  back  by  the  government.  In  either 
case,  the  contractor  must  be  compensated  fully  in  this  facilitization 
for  out-of-pocket  costs  including  costs  of  money. 

"Provide  the  professional  manpower  to  institute  an  obligatory  gov¬ 
ernment  'should  cost1  process  that  does  not  allow  (except  by  service 
system  command  approval )  award  of  production  contracts  whose  costs  vary 
more  than  10%  from  government  estimate. 

"Ensure  that  the  team  that  evaluates  proposals  for  a  program  has 
the  responsibility  for  executing  that  program.  Do  not  let  the  off-line 
technologists  determine  the  contractual  commitments. 

"These  four  suggestions,  in  sum,  attempt  to  make  it  much  more 
profitable  for  the  vendor  and  his  competition  to  bid  realistically  than 
to  play  Liar’s  Dice  in  his  proposal." 


Proposal  Evaluation 


Proposals  in  response  to  the  RFP  will  be  evaluated  by  the  PM  in 
accordance  with  the  approved  source  solicitation  plan.  Navy  in-house 
facilities  can  be  the  PM's  greatest  aid  in  the  proposal  evaluation 
process,  though  care  should  be  taken  to  ensure  than  an  in-house  proposer 
of  a  concept  is  not  also  involved  in  the  evaluation  process. 

Evaluation  criteria  should  be  flexible  enough  to  be  applied  to  the 
most  diverse  alternative  concepts  and  yet  they  must  be  sufficiently 
structured  to  permit  equitable  application  to  all  proposals.  A  partial 
list  of  critical  factors  that  must  be  addressed  includes:  the  effective¬ 
ness  of  the  proposed  concept  in  meeting  mission  need;  the  total  LCC  (and 
here  the  contractor's  estimates  should  be  verified  by  independent  esti¬ 
mates);  manning  and  training  requirements;  the  support  constraints, 
including  the  minimum  acceptable  values  for  reliability,  maintainabil¬ 
ity,  goals  for  operability  and  transportability,  and  safety  require¬ 
ments;  and  the  track  record  of  competitors,  including  their  management 
structure  and  the  competence  of  their  key  personnel.  Where  possible, 
evaluation  criteria  should  be  quantified.  Separate  evaluation  teams 
(e.g.,  cost  team,  technical  design  team,  production  team,  management 
team,  ILS  team)  will  normally  be  required  to  properly  evaluate  propo¬ 
sals. 


Figure  4-9  illustrates  one  approach  to  structuring  and  weighting 
evaluation  criteria.  The  numbers  above  the  boxes,  totaling  100,  repre¬ 
sent  the  weighting  factors.  Weightings  of  the  individual  criteria  should 
include  the  desired  value  as  the  mid-point,  the  maximum  desired  capabi¬ 
lity  as  the  goal,  and  the  minimum  acceptable  level  of  performance  as  the 
threshold.  In  establishing  each  criterion,  the  PM  should  take  into 
consideration  the  probability  of  failure  to  meet  or  exceed  the  agreed 
upon  standard  for  measurement  and  the  consequence  of  such  failure. 
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The  lowest  price  is  not  always  the  best  offer.  The  PM  should 
review  the  contractor's  assumptions  and  conditions  versus  the  "request 
for  proposal"  requirements.  Also,  the  contractor  facilities  and  resour¬ 
ces  should  be  reviewed  to  ensure  he  can  do  the  job.  Post-award-contract 
conferences  should  be  conducted  to  ensure  that  contractors  fully  under¬ 
stand  contractual  requirements  and  that  the  government  is  clear  on  what 
the  contractor  intends  to  do  and  how  he  intends  to  do  it. 


Source  Selection 

Selecting  the  proper  sources  with  which  to  contract  for  the  pro¬ 
gram's  needs  can  be  one  of  the  PM's  most  critical  tasks.  An  unqualified 
or  unreliable  source  will  jeopardize  the  success  of  the  program  regard¬ 
less  of  how  well  the  contracts  are  drawn  or  how  efficient  the  procure¬ 
ment  team  is.  The  Federal  Acquisition  Regulation  System  (FARS)  requires 
that  the  R&D  contracts  be  awarded  to  those  organizations  ''...which  have 
the  highest  competence  in  the  specific  fields  of  science  or  technology 
involved."  The  PM  must  determine  the  contractors'  "...understanding  of 
the  program  and  the  ability  to  organize  and  perform  the  contract."  The 
disciplines  governing  the  selection  of  contractual  sources  for  major 
defense  systems  are  contained  in  DODD  4105.62  and  amplified  in  NAVMAT- 
INST  4200.49. 

Source  selections  for  the  development  of  complex,  high-technology 
major  systems  will  normally  employ  a  two-stage  evaluation  process.  The 
second  of  these  -  the  evaluation  of  responses  to  the  full  solicitation  - 
entails  so  much  time,  effort  and  expense  that  to  keep  the  task  manage¬ 
able,  a  relatively  superficial,  first-stage,  preliminary  screening  is 
often  needed.  The  first-stage  evaluation  is  intended  to  eliminate  those 
candidates  who,  in  the  judgment  of  the  evaluation  team,  have  the  least 
capability  of  proposing  and  developing  a  concept  suited  to  the  mission 
need. 


A  large  number  of  firms  respond  with  expressions  of  interest  to  the 
synopsis  of  the  contractual  effort  published  in  the  Department  of  Com¬ 
merce  publication,  Commerce  Business  Daily  (CBD).  However,  before  the 
solicitation  is  issued  to  a  firm,  that  firm  must  be  judged  to  be  techni¬ 
cally  and  industrially  qualified  to  participate  effectively  in  the 
acquisition  process. 

RFPs  are  issued  to  the  firm  chosen  from  among  the  CBD  respondents. 
Respondents  may  also  be  required  to  post  a  nominal,  refundable  bond  as 
an  indication  of  their  serious  intent  and  as  a  means  of  eliminating  the 
merely  curious.  A  bidder's  conference  may  be  held  after  the  solicita¬ 
tion  is  released,  wherein  the  selected  firms  are  provided  with  the  RFP 
and  related  documents  and  given  an  opportunity  to  ask  questions  of  the 
government  team  in  attendance.  The  bidders  are  apprised  of  any  known  or 
anticipated  problem  areas  and  any  solution  or  approaches  deemed  by  the 
Navy  to  be  worthy  of  consideration,  and  are  provided  with  any  other 
information  which  might  be  helpful  in  the  development  of  a  response  to 
the  solicitation. 

The  evaluation  team  is  usually  composed  of  several  individuals  or 
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groups.  These  individuals  or  groups  represent  areas  of  expertise  essen¬ 
tial  to  an  in-depth  and  equitable  evaluation  of  the  competitor's  respon¬ 
ses.  The  evaluation  team  must  apply  established  criteria  to  determine 
how  capable  each  contractor  is  of  developing  his  concept  to  successfully 
meet  the  mission  need  within  the  given  constraints  of  time,  money,  and 
available  technology.  The  evaluation  criteria  applied  to  the  solicita¬ 
tion  will  be  framed,  as  far  as  possible,  in  quantifiable  parameters  to 
facilitate  comparison  of  the  solicitation  respondents.  The  PM  may  find 
it  important  to  have  individual  areas  evaluated  only  by  the  team  members 
expert  in  those  fields.  This  avoids  a  dilution  of  expertise  and  an 
over-democratization  of  the  selection  process. 

The  evaluation  criteria  will  typically  include  (but  not  be  limited 
to),  technical  capability,  production  capability,  past  experience,  man¬ 
agement,  the  proposed  technical  approach  or  concept,  reliability  and 
maintainability,  design  and  manufacturing  fundamentals,  estimated  cost 
of  concept  development,  and  estimated  ICC.  Great  care  must  be  taken  in 
selecting  the  evaluation  criteria  and  their  weighing  factors  to  ensure 
that  gradations  in  scores  will  be  produced  and  that  these  will  be  indi¬ 
cative  of  the  anticipated  performance  (See  Figure  4-8,  also  "Risk  Man¬ 
agement"  later  in  this  section). 

In  evaluating  the  contractor's  personnel,  it  should  be  kept  in  mind 
that  each  contractor  has  a  strong  interest  in  "putting  his  best  foot 
forward".  It  is  therefore  quite  possible  that  an  extremely  competent 
technical  team,  which  rates  highly  with  the  evaluators,  may  not  remain 
together  throughout  the  program  and  may  even  see  significant  personnel 
shifts  shortly  after  the  contract  is  let.  Legally,  there  is  nothing 
wrong  with  this.  However,  the  government  should  be  able  to  expect  that 
the  replacement  team  would  exhibit  a  comparable  capability;  and  should 
insist  that  it  do  so.  If  key  contractor  personnel  are  critical  to  the 
success  of  the  program,  a  list  of  these  individuals  can  be  incorporated 
into  the  contract.  Any  change  of  key  personnel  thus  entails  a  change  in 
the  contract  itself  and  requires  government  approval  or  re-negotiation. 
The  evaluators  should  look  not  just  at  the  qualifications  of  key  person¬ 
nel,  but  at  the  level  of  expertise  represented  by  the  contractor's 
entire  technical  team.  The  PM  must  ensure  that  the  Source  Selection 
Evaluation  Board  (SSEB)  makes  a  thorough  and  unbiased  evaluation  of  the 
proposals  and  that  the  factual  information  necessary  for  that  evaluation 
is  expeditiously  provided. 

A  final  word  about  the  effect  of  cost  on  the  source  selection 
process.  The  estimated  cost  of  the  Contractor's  proposal  will  certainly 
be  a  factor  in  the  evaluation  process.  Cost  is  a  driving  factor 
throughout  the  system  acquisition  process,  but  it  must  be  put  in  per¬ 
spective  with  other  driving  elements.  In  the  development  stage,  the 
prime  concern  is  to  find  and  engage  contractors  who  have  the  conceptual 
ideas,  manpower,  management  expertise,  facilities,  and  the  demonstrated 
experience  to  develop  a  system  capable  of  meeting  the  mission  need. 
Cost  estimates  in  the  earlier  stages  of  the  acquisition  process  are  far 
from  precise,  and  independent  estimates  of  development  and  LCC  by  an  in- 
house  activity  are  needed  to  establish  a  baseline  against  which  to 
evaluate  the  validity  of  contractor  cost  estimates.  With  due  regard  for 
its  significance,  cost  is  a  controllable  element  which  can  be  managed 
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through  carefully  drawn,  properly  executed  contracts  and  through  liberal 
use  of  competition  throughout  the  acquisition  process.  The'  cost  to 
develop  a  system  is  only  one  part,  albeit  an  important  one,  of  the 
system  LCC.  Costs  incurred  in  development,  can  return  large  dividends  in 
the  form  of  lower  production  and  maintenance  costs  as  well  as  in  improv¬ 
ed  performance. 


Contract  Award 

The  PM  must  understand  the  contracting  process  and  work  with  the 
business  manager,  technical  manager,  and  the  contracting  officer  to 
develop  the  most  appropriate  contracts.  The  technical  manager  and 
contracting  officer  may  approach  a  contract  from  opposite  directions. 
The  technical  manager's  interest  is  normally  in  a  contract  that  provides 
him  some  control  over  the  work.  He  wants  to  get  the  best  technical 
effort  and  to  this  end  may  see  the  desirability  of  some  technical  trans¬ 
fusion  to  improve  the  end  product.  The  contracting  officer  may  be  more 
concerned  about  the  legal  aspects  of  a  contract  and  he  will  usually  be 
disposed  toward  obtaining  a  contract  that  facilitates  award  and  adminis¬ 
tration.  The  PM  and  his  business  manager  must  try  to  obtain  a  contract 
that  reconciles  the  interest  of  both  the  technical  manager  and  contract¬ 
ing  officer  and  satisfies  the  need  of  the  program  for  the  particular 
phase. 

Contract  negotiations  should  be  conducted  while  the  maximum  com¬ 
petition  exists  prior  to  selection  of  the  most  promising  candidates. 

Evaluate  contractors'  claims  to  proprietary  rights  in  data.  En¬ 
courage  the  negotiation  or  agreements  by  which  unrestricted  or  royalty- 
free  use  of  data  will  be  available. 

Re-evaluate  contractors'  claims  to  proprietary  rights  in  data. 
Encourage  the  negotiation  or  agreements  by  which  unrestricted  or  royal¬ 
ty-free  use  of  data  will  be  available. 

This  continuation  of  effort  is  based  upon  the  need  to  keep  the 
selected  contractor  teams  intact  and  in  a  position  to  carry  on  the 
effort  when  the  milestone  decision  is  rendered. 

The  PM  must  rely  heavily  on  his  contracting  officer  during  the 
contract  proceedings.  One  of  the  duties  of  the  PM  is  "ensuring  communi¬ 
cations,  actions,  or  inactions  in  any  form  that  might  be  interpreted  as 
directional  to  a  contractor  shall  be  conducted  through  or  with  the 
concurrence  of  the  designated  contracting  officer."  (SECNAVINST  5000.1.) 


Contract  Technical  Management 

Government  management  of  FFP  contracts  must  be  minimal.  Indeed, 
since  the  contractor  has  agreed  to  provide  a  specific  product  on  a  given 
schedule  for  a  predetermined  price,  any  attempt  by  the  government  to 
exert  undue  management  pressure,  other  than  that  inherent  in  government 
monitoring  of  progress  and  cost,  could  be  construed  by  the  contractor  as 
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a  change  to  the  contract  with  a  concomitant  change  (increase)  In  price. 
For  a  cost  reimbursement  type  contract,  on  the  other  hand,  the  product 
may  not  be  specified  so  precisely  and  schedules  and  costs  are  "goals" 
rather  than  commitments.  This  means  that  a  series  of  significant  cost- 
performance-schedule  trade-offs  will  normally  be  made  over  the  course  of 
the  contract.  The  decisions  involved  in  these  trade-offs  are  the  re¬ 
sponsibility  of  the  government  (the  PM).  They  cannot  be  surrendered 
totally  to  the  contractor.  Even  where  the  trade-off  decisions  are  well 
within  contract  bounds,  the  PM  -  or  some  Government  representative 
assigned  responsibility  for  monitoring  the  contract  -  must  be  aware  of 
these  decisions  as  they  are  made  to  assure  that  interfaces  with  other 
portions  of  the  program  are  not  affected,  and  that  cumulative  effects  of 
this  and  other  decisions  are  within  acceptable  limits.  Also,  it  is 
imperative  that  any  problems  or  incipient  problems  relating  to  the 
contract  effort  be  identified  by  or  to  the  PM  at  the  earliest  possible 
time.  Obviously,  management  oversight  of  the  contract  is  required  to 
achieve  these  objectives. 

Contract  Monitoring.  The  actual  process  used  to  maintain  a  cur¬ 
rent  awareness  of  contract  progress  and  problems  will  vary  from  PM  to 
PM,  but,  in  general,  it  will  consist  of  some  combination  of  formal 
written  reports,  review  meetings,  and  informal  discussion,  observation, 
or  inspection  of  contractor  efforts  by  representatives  of  the  PM. 

Close  monitoring  of  the  ongoing  contracts  by  competent  technical 
and  managerial  personnel  is  essential.  Briefings  by  the  contractors  at 
regular  periods  or  milestones  will  be  necessary  and,  similarly,  new 
threat  or  operational  task  data  should  be  made  available  by  the  Navy  to 
all  contractors.  The  PM  may  employ  Navy  laboratories/  centers  and  field 
activities  during  this  period  to  identify  potential  technical  problems 
and  work  toward  their  solution.  Work  may  be  initiated  to  develop  gov¬ 
ernment-owned  alternatives  to  proprietary  processes  Incorporated  in 
concepts  proposed  by  industrial  competitors. 

Formal  Reporting  -  Cost  Schedule  Control  System  (CSCS).  The  basis 
for  any  formal  reporting  process  should  be  the  contractor's  CSCS.  DOD 
requirements  and  criteria  for  such  systems  are  established  in  DODI 
7000.10.  Implementation  guidance  is  provided  in  NAVMAT  Pamphlet  P5240 
for  major  programs  and  in  NAVMAT  Pamphlet  5244  for  less-than-major 
programs.  Several  points  bear  emphasis: 

The  contract  WBS  is  the  framework  within  which  any  of  these  system 
developments  takes  place.  It  is  important  that  the  PM  assure  that  the 
WBS  and  the  levels  to  which  it  is  extended  are  compatible  with  the 
degree  of  control  desired. 

Special  attention  should  be  paid  to  the  contractor's  analysis  of 
any  variances  between  planned  progress  and  actual  progress.  Since  such 
analyses  involve  "engineering  judgment",  it  is  imperative  that  techni¬ 
cally  competent  government  personnel  assess  them  independently  to  assure 
that  the  information  provided  the  PM  is  as  realistic  and  timely  as 
possible.  Personnel  from  the  Navy  laboratories  are  well  suited  to 
participate  in  such  assessments,  particularly  if  they  are  involved  in 
the  technical  monitoring  function  discussed  below. 
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Care  must  be  taken  to  assure  the  contract  requirements  include  the 
necessary  reports.  This  is  done  by  inserting  the  proper  entry  in  the 
CDRL,  DD  Form  1423.  Standard  DOD  Data  Item  Descriptions  are  to  be  used 
for  this  purpose.  The  reporting  requirements  must  be  appropriate  to  the 
contract  effort,  and  the  PMO  must  exert  every  effort  to  assure  that  the 
contractor  submits  complete,  accurate  reports  on  time. 

Status  Review.  Status  review  can  vary  from  quite  formal  reviews 
involving  many  people  (contractor  and,  possibly,  subcontractor  manage¬ 
ment  and  technical  personnel ,  the  PM  and  other  government  management  and 
technical  personnel)  covering  the  total  program  to  relatively  informal 
reviews  involving  fewer  persons  and  covering  only  a  segment  of  the 
contract  effort.  These  reviews,  particularly  the  larger  ones,  should  be 
held  on  a  periodic  basis,  probably  no  more  often  than  quarterly.  Provi¬ 
sions  should  be  made,  however,  for  convening  special  sessions  in  instan¬ 
ces  where  problems  appear  to  be  emerging.  Adequate  provisions  for  these 
reviews  should  be  included  in  the  contract.  Also,  the  PM  must  assure 
that  the  government  team  includes  specialists  with  the  requisite  know¬ 
ledge  to  ask  the  right  questions  and  to  assess  the  validity  and  implica¬ 
tions  of  the  answers.  He  must  also  assure  that  there  is  a  procedure  for 
guaranteeing  that  any  action  items  arising  from  these  meetings  are 
addressed  and  completed  in  a  timely  and  adequate  manner. 

Should-Cost.  Should-Cost  is  a  concept  of  contract  pricing  that 
employs  an  integrated  team  of  Government  procurement,  contract  adminis¬ 
tration,  audit  and  engineering  representatives  to  conduct  a  coordinated 
in-depth  cost  analysis  at  the  contractor's  plant.  The  purpose  is  to 
identify  uneconomical  and  inefficient  practices  in  the  contractor's 
management  and  operations  and  to  quantify  the  findings  in  terms  of  their 
impact  on  cost,  and  to  develop  a  realistic  price  objective  which  re¬ 
flects  reasonably  achievable  economies  and  efficiencies. 

A  Should-Cost  review  is  made  in  connection  with  the  procurememt  of 
all  DOD  major  systems  (ACAT  Is)  unless  the  contracting  officer  makes  a 
written  determination  that  the  potential  savings  to  be  realized  do  not 
justify  the  expense  of  such  a  review.  Should-Cost  reviews  should  also 
be  considered  in  procurement  when:  there  are  future  year  procurement 
requirements  for  substantial  quantities  of  like  items;  there  has  already 
been  some  initial  production;  the  competitive  forces  are  insufficient  to 
ensure  economical  and  efficient  performance  (e.g.,  sole  source);  and/or 
the  specification  is  comparatively  definitive  but  is  not  likely  that  the 
product  to  be  produced  will  meet  the  specification. 

In-Plant  Technical  Monitoring.  This  aspect  of  contract  monitoring 
is  frequently  the  most  effective  means  of  identifying  incipient  problems 
early,  or  providing  assistance  in  determining  solutions  to  such  pro¬ 
blems,  and  of  assessing  the  validity  or  probability  of  success  of  pro¬ 
posed  solutions.  The  important  thing  is  to  assure  that  the  government 
representative  is  technically  competent  and  that  contract  provisions 
afford  the  representative  complete  access  to  the  contractors  plant, 
personnel,  and  effort  related  to  the  contract.  While  it  may  seem  rea¬ 
sonable  to  assign  this  function  to  the  contract  administrator  at  the 
contractor's  plant,  he  is  normally  not  geared  to  accept  that  responsi¬ 
bility  (although  he  may  not  always  recognize  this  to  be  true).  Monitor¬ 
ing  a  contract  may  involve  one  or  several  engineers  in  full-time  resi- 
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dence  at  the  contractor's  plant,  or  it  may  involve  one  or  several  en¬ 
gineers  making  periodic  visits  to  the  plant.  In  any  case,  it  is  impera¬ 
tive  that  some  sort  of  memorandum  of  understanding  between  the  PM  and 
the  local  contract  administration  representative  be  developed  at  the 
outset  to  define  area  of  responsibility  and  interfaces  between  the 
program  manager's  technical  monitors  and  the  contract  administration 
organization. 

Work  Assignments.  Under  certain  circumstances,  it  may  be  necessary 
for  the  PM  to  exercise  more  positive  control  over  the  progress  and  scope 
of  the  contract  effort.  One  method  of  doing  this  is  through  the  use  of 
work  assignments.  A  work  assignment  is  a  part  of  the  contract  and 
represents  an  amplification  or  detailing  of  the  contract  work  statement 
for  some  finite  portion  of  the  effort.  It  is,  in  essence,  a  mini- 
contract  with  its  own  schedule,  budget,  and  product (s).  Effort  under  a 
work  assignment  can  be  started  only  after  the  work  assignment  is  issued 
by  the  contracting  officer  and  is  accepted  by  the  contractor.  Indeed, 
under  such  a  contract,  no  effort  can  begin  until  at  least  one  work 
assignment  is  issued.  The  use  of  a  delivery-order-type  contract  does 
impose  a  greater  burden  on  the  technical  administrator  of  the  contract 
and  on  the  contracting  officer;  however,  it  may  provide  the  essential 
control  required  in  instances  where  time-phasing  of  the  effort  of  seve¬ 
ral  program  participants  is  critical,  where  sensitive  technical  decision 
points  are  anticipated,  or  where  the  contractor  has  a  reputation  for 
inadequate  control  over  his  efforts  or  those  of  his  subcontractors.  If 
this  procedure  is  to  be  used,  't  must  be  provided  for  in  the  contract 
and  each  work  assignment  must  be  carefully  defined  and  issued  in  a 
timely  manner. 


RISK  MANAGEMENT 

The  correct  estimation  of  risk  and  its  effective  management  are 
essential  elements  of  program  management  and  have  received  increasing 
emphasis  under  the  DOD  acquisition  improvement  program.  DODD  5000.1, 
for  example,  requires  that  the  overall  acquisition  strategy,  including  a 
selection  of  which  development  phases  are  and  which  are  not  necessary, 
must  be  tailored  to  minimize  acquisition  time  and  cost  consistent  with 
the  degree  of  technical  risk  (emphasis  added).  Congress,  too,  has 
expressed  its  members  concern  with  the  risks  associated  with  weapon 
system  acquisitions,  especially  those  risks  that  impact  FSD  and  produc¬ 
tion  costs  and  schedules. 

Risk  management  is  the  process  of  identifying  areas  of  risk  that 
can  affect  the  successful  development  of  a  system,  and  taking  corrective 
action  to  reduce  the  risk  to  an  acceptable  level.  As  used  in  this 
discussion,  risk  is  a  function  of  both  the  probability  and  the  conse¬ 
quence  of  failure.  In  many  respects,  risk  management  epitomizes  effec¬ 
tive  program  management  -  systematic  reduction  of  risk  in  the  evolution 
of  a  system  acquisition.  The  methodologies  of  risk  management  are 
applicable  to  a  number  of  PM  duties,  from  overall  system  planning  to  the 
evaluation  of  proposals  and  selection  of  contractors,  and  from  the 
development  of  management  options  to  the  detailed  technical  development 
of  the  system  being  acquired  and  as  a  means  to  offset  the  effects  of 
cost  during  the  R&D  phase  of  a  weapon-system  life  cycle. 
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There  are  many  ways  to  evaluate  and  manage  the  risk  connected  with 
a  program;  the  ones  used  should  be  appropriate  to  the  program’s  size, 
complexity,  and  stage  in  the  acquisition  process.  Risk  analysis  is 
especially  important  with  respect  to  large  acquisitions  with  many  compo¬ 
nent  elements  (such  as  a  missile  with  guidance,  control,  propulsion, 
warhead,  and  initial  spares)  and  to  major  operation  and  support  elements 
such  as  depot  and  below-depot  maintenance.  In  the  very  early  stages  of 
a  system's  development,  when  uncertainty  and  hence  risk  is  greatest,  it 
should  at  least  be  possible  to  bound  a  "most  likely"  estimate  with  a 
high  and  low  variant.  The  high  and  low  estimates  should  preferably 
reflect  actual /experience  with  either  systems  or  subsystems,  or  be  based 
on  the  outcome  of  certain  events  or  policy  decisions,  rather  than  being 
arbitrary  percentage  increases  and  decreases  to  the  original  estimate. 
Figure  4-10  provides  one  guideline  for  qualitatively  identifying  the 
level  of  risk  associated  with  a  new  program. 

As  the  system  proceeds  further  into  the  acquisition  process,  more 
quantitative  treatment  of  risk  should  be  possible.  The  specific  metho¬ 
dologies  for  quantitatively  estimating  risk  are  usually  mathematical  in 
nature:  probability  theory,  Bayes1  theorem,  linear  programming,  etc.  If 
the  PM  is  not  familiar  with  these  methodologies  and  the  related  manage¬ 
ment  systems  and  network  models  such  as  Critical  Path  Method  (CPM), 
PERT,  Venture  Evaluation  and  Review  Technique  (VERT),  TRACE  concept,  and 
MARK  III,  he  should  obtain  expert  assistance  from  inhouse  Navy  or  other 
specialized  consultants.  This  assistance  should  be  obtained  before  a 
prime  contractor  is  chosen,  since  one  of  the  most  effective  applications 
of  risk  management  methodologies  is  in  the  development  of  quantitative 
evaluation  criteria  for  selecting  alternative  concepts  during  the  Con¬ 
cept  Exploration  Phase. 


TYPE  OF 

LEVEL  OF  RISK  ] 

RISK 

LOW 

MODERATE 

HIGH 

ADMINISTRATIVE 

PROGRAM  IS  REQUIRED. 
ACTIVITY  IS  ONGOING. 

REQUIRED  ACTIVITY  IS 
MODERATE  IN  COST  AND 
NONCONTROVERSIAL 

REQUIRED  ACTIVITY  HAS 
MODERATE-TO-HIGH  COST 
AND  IS  POTENTIALLY 
CONTROVERSIAL 

DESIGN 

SIMILAR  TO  PAST  OESIGNS: 
CRITICAL  PARAMETERS 

CAN  SC  ESTIMATED  WITH 
CONFIDENCE;  MANY 

DESIGN  OPTIONS  AVAIL¬ 
ABLE 

MOOERATE  EXTENSION 
FROM  PAST  OESIGNS  AND 
THE  ESTIMATED  RANGE 

OF  CRITICAL  PARAMETERS 

IS  ACCEPTABLE  TO  VEHI¬ 
CLE  DESIGN;  LIMITED 
NUMBER  OF  OESIGN 

OPTIONS  AVAILABLE 

SIGNIFICANT  EXTENSION 
FROM  PAST  DESIGNS; 
ESTIMATED  RANGE  OF 
CRITICAL  PARAMETERS 
CAUSES  SIGNIFICANT 
CONCERN  IN  THE  FINAL 
VEHICLE  DESIGN;  ONLY 
ONE  OR  TWO  OESIGN 
OPTIONS  AVAILABLE 

DEVELOPMENT 

MINIMAL  STATE-OF-THE- 
ART  EXTENSION;  SEVERAL 
FEASIBLE  APPROACHES 
DEFINED!  RAD  UNDERWAY 
AND  SUCCESSFULLY 
MEETING  CRITICAL 
MILESTONES 

MODERATE-TO-SIGNIFICANT 
EXTENSION;  FEASIBLE 
APPROACHES  DEFINED 

BUT  CURRENT  RAO  NOT 
SPECIFICALLY  ORIENTED 
TOWARD  THE  REQUIRED 
TECHNOLOGY  DEVELOP¬ 
MENTS  NECESSARY  FOR 
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FIGURE  4-10.  Preliminary  Estimate  of  Program  Risk. 
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Multi -Attribute  Utility  Model 


Making  decisions  with  incomplete  information  is  the  essence  of  risk 
management.  Use  of  the  limited  information  available  can  be  optimized 
through  a  five-step  process  based  on  the  relatively  simple  multi-attri¬ 
bute  utility  method.  The  five-step  process  consists  of: 

1.  Breaking  down  the  tasks  to  be  accomplished  into  manageable 
components  or  attributes. 

2.  Estimating  the  utility  factor,  the  relative  importance  of  each 
component  or  attribute. 

3.  Developing  a  utility  function  or  curve  which  describes  the 
utility  values  as  a  function  of  some  descriptive  variable 
(i.e.,  reliability  in  terms  of  mean  time  between  failure). 

4.  Estimating  the  risks  associated  with  attaining  the  utility 
values  chosen  for  each  attribute. 

5.  Developing  options  to  avoid  or  overcome  obstacles  to  success 
and  to  compare  alternative  paths,  solutions,  or  concepts. 

The  first  step  of  the  process  requires  breaking  down  the  program 
into  manageable  components,  since  the  estimation  (and  correction)  of 
risks  associated  with  any  large  task  is  generally  unmanageable  in  the 
aggregate.  A  WBS  taken  to  the  third  or  fourth  level  maybe  useful.  The 
level  of  detail  reached  must  be  sufficient  to  allow  a  meaningful  estima¬ 
tion  of  the  element  of  risk  that  is  associated  with  each  lowest  level 
component  or  system  attribute. 

The  second  step  in  the  process  calls  for  the  assignment  of  a  utili¬ 
ty  factor  to  each  attribute.  The  utility  factor  represents  the  relative 
importance  of  the  specific  attribute  to  the  overall  program;  for  exam¬ 
ple,  how  important  is  survivability  to  the  program  as  compared  to  range 
or  speed?  The  sum  of  the  utilities  assigned  to  the  lowest  level  attri¬ 
butes  must  equal  the  next  higher  level  until  the  total  value  for  the 
system,  usually  set  at  some  arbitrary  value  such  as  100,  or  1000  is 
achieved.  Each  attribute  should  be  considered  individually  by  the 
PM  and  his  technical  advisors.  Their  collective  experience,  expertise, 
and  intuition  should  be  applied  to  estimating  the  importance  of  a  par¬ 
ticular  attribute  to  the  overall  system  and  the  consequence  of  failure 
to  meet  the  system  goals  that  the  attribute  represents  and  to  identify¬ 
ing  likely  problems  and  their  probability. 

Having  laid  out  the  hierarchy  of  attributes  and  their  relative 
weights,  the  third  step  is  to  further  describe  each  of  the  lowest  level 
attributes  by  designing  or  using  a  variable  which  describes  it.  As  an 
example,  in  Figure  4-11  the  attribute  "System  Sensitivity"  is  described 
by  the  non-dimensional  term,  "Figure  of  Merit  (FQM)",  and  by  consulting 
with  his  technical  experts,  the  PM  has  determined  that  a  minimal  accep¬ 
table  value  of  150  would  be  usable,  a  target  vaiue  of  200  is  desired, 
and  that  a  value  for  the  F0M  of  300  would  have  even  greater  utility  if 
it  were  attainable  at  reasonable  cost  (subject  to  other  tradeoffs). 
However,  F0M  values  greater  than  300  are  probably  not  attainable,  nor 
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would  they  provide  greater  system  utility  without  making  significant 
impacts  on  the  rest  of  the  system.  Thus  a  range  has  been  established 
over  which  various  alternative  concepts  will  be  considered  for  such  an 
antisubmarine  warfare  (ASW)  system.  The  utility  of  each  of  these  values 
must  also  be  decided  on  by  the  PM  and  his  staff  and  a  utility  curve 
generated  to  connect  the  assigned  utility  points  to  be  chosen  values  of 
the  variable.  One  possible  utility  curve  is  depicted  in  Figure  4-11 (c). 

Some  type  of  utility  function  should  be  attempted  for  each  lowest 
level  attribute.  Notice,  however,  that  some  attributes  do  not  lend 
themselves  to  quantification,  or  at  least  do  not  lend  themselves  to 
credible  quantification.  For  example,  crew  morale  resulting  from  im¬ 
proved  use  environment  is  an  attribute  that  cannot  or  should  not  be 
quantified.  That  does  not  mean  that  it  should  not  be  identified  as  an 
attribute  of  importance  in  comparing  alternative  ASW  concepts.  It  is 
just  that  any  attempt  to  quantify  it  would  not  aid  in  the  analysis 
process,  and  might  actually  hinder  it. 

What  has  been  developed  after  three  steps  is  a  hierarchical  matrix, 
weights  assigned  to  the  various  attributes  and  subattributes  of  the 
matrix  and,  where  possible,  utility  functions  for  each  of  the  lowest 
level  attributes.  Next,  various  alternative  concepts,  designs  or  sche¬ 
dules  which  might  be  submitted  or  used  are  scored  through  use  of  the 
matrix  to  help  decide  which  are  best.  For  example,  assume  that  some 
particular  system  concepts  have  been  proposed  for  consideration..  Assess¬ 
ments  must  be  made  as  to  each  concept's  area  coverage,  sensitivity, 
LCC,  fuel  consumption,  manning  levels,  skill,  specialized  training 
required,  and  so  forth.  These  assessments  can  take  the  form  of  point 
estimates  or  of  probability  distribution,  as  indicated  in  Figure  4- 
11(d).  Once  these  assessments  have  been  made,  the  various  concepts  can 
be  scored  to  aid  in  the  process  of  deciding  upon  the  optimum  system. 

Techniques  for  performing  the  first  four  steps  can  be  generalized 
(see  Figure  4-11),  and  significant  progress  in  risk  management  can  be 
made  by  effectively  accomplishing  these  steps. 

Effective  accomplishment  of  the  fifth  step  of  the  risk  management 
process  will  depend  upon  the  talents  of  the  PM,  his  subordinates,  and 
contractors,  and  the  ingenuity  that  they  can  bring  to  bear  on  specific 
problems.  This  step  may  involve  accepting  an  increased  risk  for  one  of 
several  attributes  so  as  to  be  able  to  reduce  risk  in  areas  where  the 
payoff  will  be  greater,  or  even  to  assume  greater  overall  risk  if  the 
potential  benefits  significantly  outweigh  the  possible  consequences  of 
failure. 

As  an  adjunct  to  the  five-step  risk  management  process,  it  is 
useful  to  construct  time  and  contingency  fund  hedges  and  to  assign 
monitors  who  will  bring  likely  problems  to  the  PM's  attention  in  a 
timely  manner.  The  more  potential  problems  that  can  be  isolated  in  this 
manner,  the  better  equipped  the  PM  will  be  to  deal  with  them  should  they 
develop.  It  has  been  accurately  observed  that  "it  isn't  the  known 
unknowns  that  will  get  you,  it  is  the  unknown  knowns". 

The  five-step  methodology  outlined  here  must  be  viewed  as  a  deci¬ 
sion-aiding,  not  a  decision-making  device.  This  applies  to  all  risk 
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FIGURE  4-11.  Risk  Management  Evaluation  Process. 


management  methodologies.  It  is  very  tempting,  especially  for  practi¬ 
tioners  of  a  particular  methodology,  to  view  the  procedures  involved  as 
a  replacement  for  management  judgment.  The  methodology  only  provides  a 
mechanism  whereby  proposed  changes  or  alternative  concepts  can  be  eval¬ 
uated.  When  a  change  or  choice  is  suggested,  its  ramifications  can  be 
assessed  according  to  the  attributes,  weights,  and  utility  functions  in 
order  to  determine  whether  it  causes  a  net  gain  or  loss.  The  main 
advantage  of  this  approach  is  the  degree  to  which  the  communications 
process  is  facilitated  and  enhanced.  The  explicitness  of  the  matrix  of 
attributes,  the  weights,  the  utility  functions,  and  the  assessed  proba¬ 
bility  distributions  tend  to  make  the  process  self-correcting.  The 
second  advantage  is  the  achievement  of  a  much  greater  degree  of  objec¬ 
tivity  in  the  risk  analysis  and  assessment  processes  than  might  other¬ 
wise  be  expected.  When  opinions  are  displayed  and  critiqued,  narrow¬ 
minded  orientations  give  way  to  a  more  balanced  outlook. 


Budgeting  for  Program  Risk 

Until  recently,  PMs  who  requested  funds  specifically  to  cover 
program  uncertainties  usually  found  those  funds  deleted  by  the  DON,  DOD, 
OMB,  or  Congress.  As  a  result,  PMs  either  budgeted  an  undisclosed 
management  reserve  (typically  spread  in  small  amounts  across  the  program 
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tasks  or  concentrated  in  an  expendable  element  that  could  be  cut  without 
affecting  the  program)  or  suffered  cost  and  schedule  overruns  when 
unprogrammed  and  unbudgeted  events  occurred.  Improper  budgeting  or 
inevitable  overruns  are  no  longer  the  extent  of  the  PM's  options.  Action 
in  Deputy  Secretary  of  Defense  (DEPSECDEF)  Carlucci's  initiatives  to 
improve  the  acquisition  process  calls  for  the  services  to  quantify  risk 
associated  with  an  acquisition  and  to  expand  the  use  of  budgeted  funas 
to  deal  with  the  uncertainty. 

The  Navy  has  responded  to  this  directive  by  requiring  that  each 
PM  include  risk  assessment  and  the  means  for  dealing  with  it  in  his  ac¬ 
quisition  strategy,  and  that  he  include  within  the  acquisition  strategy 
a  financial  strategy  describing  realistic  funding  necessary  to  achieve 
the  acquisition  objective.  By  Milestone  II,  is  must  be  shown  that  the 
technical  and  operation  risks  have  been  reduced  to  acceptable  levels. 

Total  Risk  Assessing  Cost  Estimate  (TRACE)  Concept.  The  Navy  is 
evaluating  the  use  of  the  TRACE  concept,  developed  by  the  Army,  as  a 
means  for  budgeting  for  risk.  TRACE  is  designed  to  aid  the  PM  in 
estimating  the  costs  associated  with  program  risks  and  providing  a  means 
for  budgeting  sufficient  funds  to  react  to  these  risks.  The  TRACE  pro¬ 
cess  begins  with  a  PM's  baseline  cost  estimate  (BCE).  The  BCE,  which 
is  the  PM's  comprehensive  evaluation  of  the  estimated  LCC  for  the  pro¬ 
gram,  is  generated  by  standard  estimating  procedures  and  includes  R&D, 
investment,  operational,  and  logistics-support  costs.  The  R&D  phases 
are  then  re-examined  for  identifiable  risk  areas,  e.g.,  technical  design 
changes  to  correct  deficiencies,  re-scheduling  around  technical 
problems,  additional  testing  to  verify  design  corrections,  additional 
hardware  to  support  design  modifications,  schedule  slippages  caused  by 
late  deliveries,  non-negligent  human  error,  etc.  Costs  to  the  program 
for  changes  in  requirements,  inflation,  and  pay  increases  are  not  to  be 
included  in  the  TRACE.  The  identified  risk  areas  are  then  incorporated 
into  the  PM's  estimating  methodology  and  a  new  estimate  for  the  R&D 
phase,  the  TRACE,  is  made.  The  TRACE  allows  for  a  50-50  chance  of 
producing  either  a  cost  overrun  or  cost  underrun.  This  additional 
amount  of  money  is  then  held  as  a  risk  or  TRACE  funding  deferral.  At 
least  four  different  means  have  been  developed  and  used  for  obtaining 
the  TRACE.  Only  two  are  discussed  here:  the  risk-factor  method  and  the 
probabi 1 i sti c-network-model i ng  method . 

The  risk  factor  method  involves  breaking  the  R&D  phase  activities 
down  into  sub-elements  using  WBS  defined  in  MIL-STD  881 A  and  discussed 
earlier  in  this  section.  The  cost  for  the  R&D  is  computed  by  totaling 
the  costs  associated  with  each  sub-element  level  to  form  the  BCE.  The 
risk  inherent  in  each  sub-element  is  subjectively  determined,  in  a 
manner  similar  to  that  described  in  the  discussion  on  the  multi-attri¬ 
bute  utility  model,  and  an  additional  cost  for  that  risk  estimated.  The 
TRACE  estimate  for  the  sub-element  is  simply  the  BCE  plus  the  cost  to 
cover  risk.  The  total  TRACE  for  the  R&D  phases  is  generated  by  aggre¬ 
gating  the  sub-element  TRACES.  In  most  cases,  the  TRACE  is  then  divided 
into  budget  years  and  the  risk  deferral  for  each  year  is  separately 
funded. 

The  probabilistic-network-modeling  method  is  basically  a  combina¬ 
tion  of  general  program  evaluation  and  review  techniques  such  as  PERT 


and  Monte  Carlo  simulation.  Cost  and  schedule  uncertainties  are  incor¬ 
porated  (as  in  the  risk  factor  method)  into  the  model,  which  is  then 
exercised  in  successive  computer  simulation  runs.  The  output  provides  a 
distribution  of  the  estimated  program  costs  and  schedule. 

The  value  of  the  TRACE  concept  in  program  management  is  that  it 
provides  the  PM  with  additional  money  over  and  above  his  base  cost 
estimate  and  allows  him  to  react  to  unprograrmed  occurrences  without 
asking  for  supplemental  appropriations.  TRACE  is  valuable  to  the  acqui¬ 
sition  system  in  that  it  promotes  honesty  and  improves  communications 
with  command  and  Congress. 

The  Navy  TRACE  management  concept  presently  being  evaluated  by 
NAVAIR  differs  from  the  TRACE  concept  used  by  the  Army.  The  Navy  plans 
to  hold  the  TRACE  deferral  funds  at  the  systems  command  level.  Release 
of  funds  will  require  the  approval  of  the  SYSCOM  commander.  Thus, 
management  of  the  Navy  TRACE  funds  will  occur  two  levels  lower  in  the 
hierarchy  than  in  the  Army,  which  holds  the  TRACE  funds  at  the  secreta¬ 
riat  level.  Additional  information  on  the  use  of  the  TRACE  system  by 
the  Navy  can  be  obtained  from  NAVAIRSYSCOM,  AIR-12,  (202)  692-7988,  or 
AUT0V0N  222-7988.  The  Army  also  has  published  a  number  of  information 
pamphlets  on  the  TRACE  concept  (series  ALM-63-4476) .  These  can  be 
obtained  from  the  U.S.  Army  Logistics  Management  Center,  Fort  Lee, 
Virginia  23801.  A  more  extensive  treatment  of  risk  can  be  found  in  the 
publication  Risk  Assessment  Techniques  -  A  Handbook  for  Program  Manage¬ 
ment  Personnel,  which  is  published  by  the  Defense  Systems  Management 
College  (DSMC),  Fort  Belvoir,  Virginia. 

SYSTEM  ENGINEERING 

It  is  easy  to  put  a  system  together  but  difficult  to  put  the  "best" 
system  together.  System  engineering  is  the  discipline  that  ties  toge¬ 
ther  all  aspects  of  a  program  to  assure  that  the  individual  parts, 
assemblies,  subsystems,  support  equipment  and  associated  operational 
equipment  will  effectively  function  as  intended  in  the  operational 
environment.  Early  application  of  a  disciplined  and  thorough  system 
engineering  approach  will  ensure  that  development  of  the  system  proceeds 
more  quickly  and  smoothly.  Problems  which  do  occur  can  be  scoped  and 
resolved  more  efficiently.  System  engineering  should  assure  that  an 
organized,  systematic  understanding  of  all  aspects  of  the  system  and  the 
program  have  been  developed  and  documented. 

A  useful  definition  of  system  engineering  is  given  in  MIL-STD  449. 

"System  engineering  is  the  application  of  scientific  and  en¬ 
gineering  efforts  to  (a)  transform  an  operational  need  into  a 
description  of  system  performance  parameters  and  a  system 
configuration  through  the  use  of  an  incentive  process  of 
definition,  synthesis,  analysis,  design,  test  and  evaluation; 

(b)  integrate  related  technical  parameters  and  assure  compati¬ 
bility  of  all  physical,  functional  and  program  interfaces  in  a 
manner  which  optimizes  the  total  system  definition  and  design; 

(c)  integrate  reliability,  maintainability,  safety,  surviva¬ 
bility,  human  and  other  such  factors  into  the  total  engineer¬ 
ing  effort". 
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Although  the  system  approach  must  be  practical  at  all  engineering 
levels,  it  is  the  program's  system  engineers  who  must  provide  the  direc¬ 
tion  and  discipline  to  the  several  contractor  and  in-house  subsystem 
design  teams  if  optimization  of  the  system  rather  than  the  subsystem  is 
to  be  achieved.  The  system  engineering  team  will  establish  an  analyti¬ 
cal  framework  within  which  broad  system  requirements  (Figure  4-12)  are 
translated  into  concrete  specifications  and  these  in  turn  into  specific 
subsystems,  assemblies,  subassemblies,  and  components.  The  application 
of  system  engineering  management  to  any  program  must  be  consistent  with 
the  nature,  complexity,  and  scope  of  the  system  and  the  imposed  contrac¬ 
tual  requirements. 

In  an  acquisition  program,  the  system  engineering  management  disci¬ 
pline  includes  performing  the  following  tasks: 

o  Planning  controlling,  and  applying  system  engineering  to 
transform  a  contractually  defined  operational  need  into  a 
system/end-product  definition  and  an  optimized  design  that 
incorporates  equipment,  personnel,  facilities,  computer 
programs,  and  procedural  data.  Tho  definition  should  be  in 
terms  of  required  system/end-product  performance  parameters 
and  planned  technical  approaches  tailored  to  the  program  re¬ 
quirements. 

o  Identifying,  providing,  and  controlling  the  detailed  defini¬ 
tion  of  the  contract  WBS  in  terms  of  technical  tasks,  assuring 
consistency  and  correlation  of  program  technical  requirements. 

o  Identifying  high-risk  a*"eas  and  continually  assessing  their 
impact  on  the  program. 

o  Determining  program  technical  requirements  and  integrating  the 
specialty  efforts  and  such  disciplines  as  configuration  man¬ 
agement  and  data  management. 

o  Providing  the  rationale  and  the  definitive  specifications  for 
all  hardware/software,  facilities,  and  personnel  required  to 
carry  out  and  support  contractual  requirements. 

o  Establishing  appropriate  baselines  and  management  reviews  to 
permit  effective  engineering  change  control  and  monitoring. 

o  Establishing  the  rationale  for  ensuring  that  engineering  deci¬ 
sions  leading  to  the  selection  of  design  alternatives  are 
based  upon  system/end-product  cost  effectiveness  considera¬ 
tions. 

o  Establishing  traceability  of  defined  significant  engineering 
decisions  to  the  system  engineering  management  activities  on 
which  they  are  based. 

o  Planning  system  T&E  programs  to  ensure  meeting  development  and 
mission  requirements,  evaluating  -  ;ievement,  and  reporting 
technical  performance  against  p  jram  objectives  both  for 
early  identification  of  problems  ai  for  visibility  by  manage- 
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merit  so  that  timely  corrective  action  can  be  taken. 

o  Providing  appropriate  and  timely  redefinition  of  program  tech¬ 
nical  requirements  in  response  to  changes  directed  by  the 
customer  or  the  problems  identified  through  evaluation  of 
performance , 
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FIGURE  4-12.  System  Requirements. 


One  guiding  principle  in  the  application  of  system  engineering  is 
that  organization  of  the  system,  not  the  subsystem,  is  paramount.  It  is 
not  enough  to  design  efficient  subsystems  and  then  hook  them  together, 
though  this  tendency  frequently  exists  when  several  design  teams  are 
working  on  discrete  subsystems  or  subassemblies.  The  PM,  though  his 
system-engineering  team,  must  see  that  the  trees  do  not  obscure  the 
forest  and  that  system  optimization,  rather  than  sub-optimization, 
guides  the  acquisition  process. 


Design  Reviews 

Formal  and  informal  design  reviews  are  used  to  determine  the  ade¬ 
quacy  of  contractor  and  Navy  in-house  efforts  toward  achieving  design 
goals.  Participants  should  include  design  attribute  specialists  in 
reliability,  maintainability,  safety,  and,  particularly,  logistic  sup- 
portability.  Reviews  should  include  a  preliminary  design  review,  a 
critical  design  review,  a  design  certification  review,  a  functional 
configuration  audit,  a  physical  configuration  audit,  and  a  first-article 
configuration  inspection. 
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Preliminary  Design  Review  (PDR).  The  PDP.  is  conducted  by  the 
developing  agency  prior  to  initiation  of  detailed  design  of  the  proto¬ 
type  subphase  and  subsequent  fabrication  of  test  articles.  The  PDR 
examines  the  basic  design  approach  for  a  configuration  item  to  see  if  it 
will  meet  specific  performance  requirements  and  be  compatible  with  other 
configuration  items  in  the  overall  system.  The  PDR  normally  occurs  at 
the  end  of  the  engineering  subphase  and  establishes  the  basis  for  re¬ 
lease  to  prototype  production. 

Critical  Design  Review  (CDR).  The  CDR,  a  formal  review  of  the 
detailed  design  of  a  configuration  item,  is  performed  by  the  PM  late  in 
the  prototype  subphase  when  the  design  detail  is  essentially  complete, 
but  prior  to  drawing-release  and  fabrication  of  formal  test  articles. 
This  review  will  help  determine  the  maturity  of  the  system  and  formally 
establish  the  design  as  the  basis  for  activities  such  as: 

o  Preparation  of  provisioning  documentation 

o  Preparation  of  technical  manuals 

o  Provisioning  of  initial  spares 

o  Personnel  training 

The  primary  purpose  of  the  CDR  is  to  formally  identify  the  engine¬ 
ering  documentation  that  defines  the  configuration  item.  At  CDR,  the 
degree  of  completeness  of  the  preliminary  Physical  Configuration  Identi¬ 
fication  (PCI)  is  assessed. 

Design  Certification  Review  (DCR).  The  OCR  is  a  formal  review, 
conducted  by  the  developing  agency,  of  the  final  design  (preproduction 
prototype)  subsequent  to  qualification  testing  and  prior  to  OT&E  and 
production  start. 

Functional  Configuration  Audit  (FCA).  The  FCA  will  be  performed  on 
a  prototype  or  pilot  production  unit  that  is  represented  to  be  a  physi¬ 
cal  and  functional  equivalent  of  the  product  described  by  the  design 
disclosure  for  the  product  baseline  configuration.  This  is  to  verify 
that  the  item  functions  as  required  by  the  product  baseline  configura¬ 
tion  specifications.  The  FCA  establishes  the  functional  requirements  to 
which  subsequent  manufactured  articles  must  conform. 

Physical  Configuration  Audit  (PCA) .  The  PCA  will  be  performed  on  a 
prototype  or' pi  lot  production  unit  that  is  represented  to  be  a  physical 
and  functional  equivalent  of  the  product  described  by  the  design  dis¬ 
closure  for  the  product  baseline  configuration.  This  audit  establishes 
the  basic  or  initial  product  physical  configuration  identification  to 
which  subsequently  manufactured  items  must  conform  until  authorized 
changes  are  incorporated. 

Preproduction  Reliability  Design  Review  (PRDR).  The  PRDR  is  a  for¬ 
mal  technical  review  to  obtain  mutual  agreement  between  the  developing 
agency,  the  test  agency,  the  contractors,  and  the  vendors  that  the  sys¬ 
tem's  established  reliability  is  or  is  not  acceptable  to  support  com¬ 
mencement  of  production  and  deployment.  The  PRDR  will  be  held  between 
completion  of  initial  initial  operational  test  and  evaluation  ( I OT&E 
and  the  CEB/CMC/CNM  first  major-production  decision  point.  During  the 
PRDR,  weapon  system  maturity  will  be  evaluated  primarily  on  the  basis  of 
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the  Navy  technical  and  operational  test  results.  This  includes  all 
failure  reports,  failure  analysis  report,  completed  and  recommended 
corrective  actions,  and  planned/implemented  retests.  While  all  weapon 
system  acquisitions  are  candidates  for  PRDR,  only  those  selected  by  the 
DCNM(R&M)  will  require  this  review. 

First-Article  Configuration  Inspection  (FACI).  FAC  I  is  conducted  by 
the  developing  agency  on  the  as-produced  design  following  manufacture 
and  acceptance  testing  of  the  first  end-item  configured  for  delivery  to 
the  Fleet. 


COST  MANAGEMENT/LIFE-CYCLE  COSTING  (LCC) 

The  PM  is  faced  with  the  dilemma  of  developing  a  satisfactory 
system  in  an  environment  of  (1)  changing  enemy  threat,  (2)  increasing 
cost  and  shortages  of  skilled  personnel,  (3)  increasing  cost  of  systems 
development  and  critical  materials,  and  (4)  decreasing  real  budgets. 
Within  the  confines  of  this  dilemma,  the  PM  must  get  the  most  system  for 
the  least  dollars  and  he  must  face  the  fact  that  as  national  priorities 
shift,  unaffordable  projects  will  be  cancelled.  The  object  of  cost 
management  and  life-cycle  costing  is  to  obtain  sufficient  quantities  of 
an  operationally  acceptable  system  at  an  affordable  cost.  To  do  this, 
the  PM  must  utilize  cost  trade-offs,  with  emphasis  on  LCC,  beginning 
early  (Concept  Exploration  Phase)  and  continuing  throughout  the  program. 
The  challenge  to  the  PM  is  to  reduce  system  lifetime  costs,  achieve  an 
acceptable  military  performance,  and  meet  operational  capability  sche¬ 
dules  -  all  simultaneously.  Figure  4-13  breaks  down  total  system  cost 
into  its  component  elements. 


FIGURE  4-13.  Total  System  Cost  Elements. 
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In  the  process  of  cost  management,  cost  parameters  are  established 
to  discipline  the  acquisition  process.  Discrete  cost  projection  ele¬ 
ments  (e.g.,  unit  production  costs,  operating  and  support  cost)  are 
established  as  requirements.  System  development  is  continuously  evalu¬ 
ated  against  these  cost  goals  and  thresholds  with  the  same  rigor  as  that 
applied  to  technical  and  schedule  requirements. 


DESIGN-TO-COST  (DTC) 

DTC  is  an  acquisition  management  technique  that  establishes  cost  as 
an  active  design  parameter  -  a  parameter  equal  in  importance  to  perfor¬ 
mance,  schedule  and  supportability.  The  DTC  concept  recognizes  that 
there  are  minimum  performance  requirements  needed  is  a  system  is  to  be 
capable  (performance  floor),  and  that  this  capability  must  be  achieved 
within  a  certain  cost  (cost  ceiling)  if  the  system  is  to  be  affordable. 
Within  this  performance  floor  and  cost  ceiling  that  are  a  range  of 
acceptable  solutions  that  will  provide  the  cost-effective  system.  Dur¬ 
ing  development,  these  boundaries  -  performance  floor  and  cost  ceiling  - 
provide  designers  with  the  flexibility  for  trade-offs  to  achieve  an 
optimum  balance  among  numerous  program  parameters.  Cost  is  critical  to 
this  trade-off  process  and  is  addressed  throughout  the  system  life 
cycle.  See  DODD  4245.3,  "Design-to-Cost"  and  NAVMAT  P5242,  "Design-to- 
Cost  Guide  -  Life  Cycle  Cost  as  a  Design  Parameter". 

DTC  focuses  on  all  acquisition  and  Operations  and  Support  (O&S) 
costs  of  the  LCC  equation  except  R&D.  An  acquisition  DTC  goal  is  ex¬ 
pressed  in  the  form  of  flyaway  (roll  away,  sail  away)  costs.  DTC  O&S 
goals  may  be  expressed  in  dollars  or  other  measurable  factors,  (e.g., 
reliability,  maintainability,  manpower)  that  are  design  controllable, 
significantly  affect  O&S  costs  and  can  be  measured  during  test  and 
evaluation. 

Each  program  should  establish  a  LCC  figure  to  include  a  DTC  acqui¬ 
sition  component  and  a  DTC  O&S  component.  These  DTC  figures  are  stated 
as  objectives  in  the  conceptual  phase  but  are  in  terms  of  goals  and 
thresholds  by  the  time  of  Milestone  II.  In  this  way,  DTC  becomes  con¬ 
trol  tool  for  both  the  contractor  and  the  PM  for1  review  at  each  signifi¬ 
cant  points  during  the  life  cycle. 

From  the  beginning,  the  focus  is  to  identify  alternatives,  trade¬ 
offs,  incentives  and  areas  for  corrective  actions  that  will  reduce  cost 
without  sacrificing  system  effectiveness.  Concepts  may  include  built-in 
test  for  ease  of  maintenance,  use  of  value  engineering,  standard  support 
equipment  and  prototyping  for  production  along  with  many  other  ideas  to 
reduce  total  cost. 


COST  ESTIMATES  &  CONTROL  TECHNIQUES 

The  program's  cost  estimating  and  control  techniques  must  be  tai¬ 
lored  to  arrive  at  the  best  estimate  and  to  control  the  systems  total 
LCC.  In  the  order  of  their  occurrence,  the  different  system  cost  ele¬ 
ments  may  be  separated  into  the  following  categories: 
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1.  Research  and  Development  (R&D).  Costs  primarily  associated 
with  the  development  of  a  new  system,  or  capacity,  to  the  point  at  which 
it  is  ready  for  procurement  and  operational  use. 

2.  Investment.  Costs  beyond  the  development  phase  to  introduce  a 
new  system  or  capability  into  operational  use,  including  production, 
installation,  and  checkout,  as  well  as  special  facilities  and  repair 
equipment  required  to  support  the  system  in  the  fleet. 

3.  Operation  and  Support.  Recurring  costs  of  operation,  mainten¬ 
ance,  and  logistic  support  of  the  system. 

The  purpose  of  identifying  and  displaying  system  costs  in  separate 
categories  is  to  facilitate  their  evaluation  by  the  decision  maker  or 
planner.  This  categorization  recognizes  the  fact  that  the  cost  associ¬ 
ated  with  each  phase  of  a  system's  life  cycle  will  vary  greatly.  In 
some  instances,  cost  will  be  very  sensitive  to  the  number  of  units  of 
the  system  to  be  procured.  While  R&D  costs  are  relatively  independent 
of  the  number  of  system  units  to  be  procured,  investment  costs  are  a 
function  of  both  unit  cost  and  the  number  of  system  units  to  be  deploy¬ 
ed.  R&D  and  investment  costs  are  considered  as  one-time  costs.  By 
contrast,  operation  and  support  costs  are  recurring  costs  and,  for 
systems  with  long  service  lives,  may  account  for  the  major  part  of  the 
system's  total  LCC. 

The  PM  and  his  team  should  avoid  viewing  cost  management  as  simply 
a  tool  or  a  discipline  to  be  applied.  They  must  view  it  as  a  develop¬ 
mental  approach  if  it  is  to  be  effective.  Cost  management  must  be 
emphasized  as  a  framework  for  system  development,  not  a  program  appen¬ 
dage  but  a  pervasive  activity  for  the  life  of  the  program.  To  establish 
a  cost-conscious  environment  and  to  reap  the  maximum  berefit  attainable 
while  design  possibilities  are  wide  open,  the  concepts  cf  cost  manage¬ 
ment  must  be  introduced  and  emphasized  from  the  start  cf  the  Concept 
Exploration  Phase. 

During  the  Concept  Exploration  Phase,  the  PM  must  establish  a 
method  for  making  LCC  comparisons  among  the  several  concepts  being 
explored.  The  WBS  is  a  powerful  tool  for  use  in  making  these  compari¬ 
sons.  The  WBS  element  matrix.  Figure  4-4,  discussed  under  "The  Manage¬ 
ment  Process",  can  be  used  to  identify  all  hardware  and  effort  expected 
over  the  life  of  the  project.  The  various  cost  elements  (labor  and 
overhead,  materials,  contracts,  etc.)  can  then  be  considered  for  each 
cell  of  the  matrix.  The  aggregation  of  the  cost  associated  with  each 
cell  is,  then,  life-cycle  costing.  Analysis  of  individual  cell  cost/ 
performance/schedule  trade-offs  provides  basic  information  for  effective 
cost  management. 

The  PM  must  consider  the  best  balance  between  cost/performance/ 
schedule/logistic  supportability.  For  a  proper  balance  between  these 
considerations  to  evolve  in  a  climate  of  flexibility,  rigid  goals  should 
not  be  established  prematurely. 

System  design  iteration  must  continue  through  system  validation 
with  cost/performance/schedule/logistic  supportability  goals  stabilizing 
at  Milestone  II.  On  the  cost  side  of  design  trade-offs,  the  PM  must 
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consider  net  only  investment  costs,  but  operating  costs  as  well  since 
the  latter  are  where  major  cost  savings  may  be  realized.  Affordability 
must  be  considered  on  both  an  absolute  and  relative  basis.  Without 
realistic  affordability  estimates,  cost  and  performance  requirements  may 
be  established  at  levels  which  lead  to  unaffordable  systems  or  systems 
that  are  insufficient  to  counter  the  threat. 


COST  GROWTH  AND  INDEPENDENT  COST  ANALYSIS 

DOD  has  been  taken  to  task  many  times  and  from  many  quarters  on  the 
subject  of  cost  growth  connected  with  the  acquisition  of  weapon  systems. 
One  of  the  causes  of  apparent  cost  growth  has  been  the  use  of  inaccurate 
cost  estimates.  Good  estimates  of  not  only  development  but  of  LCC  are 
necessary  to  properly  allocate  limited  resources.  Accurate  cost  esti¬ 
mates  are  also  required  within  industry  to  enable  competitive  bidding  on 
contracts  and  ensure  reasonable  profit. 

In  order  to  provide  constructive  assistance  to  the  PM  in  the  devel¬ 
opment  of  credible  estimates  and  adequately  advise  management,  a  number 
of  independent  cost  estimating/assessment  groups  have  been  established. 
"Independent  cost  estimate/assessment"  means  that  the  analysis  group  is 
organizationally  separate  from  (and  neither  a  proponent  nor  an  opponent 
of)  the  weapon  system  acquisition.  Such  independent  groups  have  been 
established  at  OSD,  SECNAV/CNO,  NAVMAT ,  SYSCOM,  and  R&D  Center  levels. 

The  highest  DOD  organization  level  responsible  for  performing  inde¬ 
pendent  cost  analysis  is  the  OSD  Cost  Analysis  Improvement  Group  (CAIG). 
The  primary  function  of  the  CAIG,  as  set  forth  in  DODD  5000.4,  is  to 
provide  the  Defense  Systems  Acquisition  Review  Council  (DSARC)  with  a 
review  and  evaluation  of  both  independent  and  PM  cost  estimates  that  are 
prepared  by  the  services  for  presentation  to  the  DSARC  at  milestone 
reviews.  These  CAIG  cost  reviews  consider  all  elements  of  LCC,  includ¬ 
ing  R&D,  investment,  and  operating  support. 

Similarly,  the  SECNAV/CNO  Advisor  for  Resource  Analysis  and  his 
staff  (OP-917)  generate  and  provide  and  independent  estimate  and  assess¬ 
ment  of  LCC  of  weapon  system  acquisitions  for  milestone  reviews  by  the 
DNSARC  and  the  Chief  of  Naval  Operations  Executive  Board  (CEB).  This 
independent  cost  estimate/assessment  is  usually  based  upon  parametric 
techniques  that  are  different  from  the  techniques  used  by  PMs;  typical¬ 
ly,  a  top-down  versus  bottom-up  review.  The  SECNAV/CNO  Advisor  provides 
a  critical  review  and  analysis  of  cost,  schedule,  performance,  and  other 
pertinent  financial  management  aspects  of  acquisition  category  (ACAT)  I, 
IIS  and  IIC  programs  for  the  CNO  and  the  Deputy  Under  Secretary  of  the 
Navy,  Financial  Management  (DUSN(FM))  prior  to  DNSARC  proceedings.  NAV- 
MA1  01F4,  the  inrector  of  Cost  Analysis  Division  has  the  responsibility 
and  capability  for  review  and  independent  parametric  estimates  For  ACAT 
I  to  ACAT  III  programs  as  part  of  the  NAVMAT  review  process  of  such 
programs.  The  object  of  the  independent  estimate/assessment  is  to 
advise  decision  makers  of  the  reasonableness  of  the  PM's  LCC  estimate. 

Periodic  Reports.  In  addition  to  the  cost  analysis  required  as 
part  of  the  milestone  review  process,  the  PM  will  be  required  to  provide 
various  command  levels  with  periodic  reports.  This  is  necessary  to  keep 
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command  informed  of  the  program's  progress  as  compared  to  schedules  and 
projected  costs.  Among  these  reports  are  the  Selected  Acquisition 
Reports  (SARs)  for  Congress,  required  quarterly  following  Milestone  I 
for  major  programs  (described  earlier  on  page  3-XX),  and  the  Acquisition 
Program  Status  Report  of  the  NAVMAT  Selected  Acquisition  Tracking  System 
(NSATS)  (discussed  on  page  3-XX)  required  for  ACAT  I,  IIS  and  IIC  pro¬ 
grams.  Other  SYSCOM-specific  reports  are  also  required. 

Availability  of  Assistance.  The  PM  has  a  variety  of  sources  for 
assistance  in  LCC  estimation.  These  include  the  SYSCOMs  and  Navy  R&O 
laboratories/centers,  which  can  be  tasked  to  provide  assistance  in  the 
actual  preparation  of  the  cost  estimates  and  proposed  thresholds.  Or¬ 
ganized  cost  analysis  groups  exist  at  the  NWC,  NSWC,  and  NACC.  These 
groups  are  dedicated  to  cost  analysis  in  their  respective  mission  areas. 
The  other  laboratories,  while  not  maintaining  formalized  cost  analysis 
groups,  have  individuals  with  the  technical  expertise  in  specific  fields 
to  assist  the  PM  in  early-on  DTC/LCC  considerations.  In  addition,  the 
PM  will  want  to  consult  the  DOD  Guide  on  Life-Cycle  Costing,  LCC  Guid¬ 
ance  for  Naval  Aircraft,  Ships,  and  Missiles  (available  from  NAVMAT- 
016),  DODD  5000.28  Design  to  Cost,  SECNAVINST  4000.31  Life-Cycle  Cost¬ 
ing,  and  NAVMATINST  P-5242  Joint  Design  to  Cost  Guide:  Life  Cycle  Cost 
as  a  Design  Parameter. 

In  summary,  the  PM  must  do  the  following  if  he  is  to  have  a  viable 
cost  management  program  philosophy  for  his  program: 

1.  Establish  an  environment  where  cost/performance/schedule/ 
logistic  supportability  are  given  equal  consideration  in  the  selection 
of  system  concepts  and  design  alternatives. 

2.  Emphasize  flexibility  in  the  imposition  of  early  cost  require¬ 
ments. 

3.  Emphasize  and  implement  cost  management  disciplines  at  the 
front  end  of  the  program. 

4.  Develop  an  in-house  cost-modeling/cost-estimating  capability 
during  concept  exploration  for  subsequent  cost  estimating  and  tracking. 

5.  Use  affordability  analysis  as  the  basis  for  cost  goals. 

6.  Develop  a  structure  for  accommodating  cost  goals  at  both  life- 
cycle-costing  and  unit-flyaway  levels. 

7.  In  conjunction  with  6,  develop  an  integrated  PM's  office 
structure  for  life-cycle  costing  modeling  and  WBS  planning  control. 

8.  Encourage  industry  feedback  on  DTC/LCC  estimating  approaches. 


RELIABILITY,  MAINTAINABILITY  AND  AVAILABILITY  (RM&A) 

One  of  principal  concerns  of  the  CN0  is  the  state  of  Fleet 
readiness.  A  major  contributor  to  this  condition  is  the  relatively  low 
reliability  of  systems  and  components  and  the  inherent  difficulty  in 
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maintaining  them  at  sea.  These  deficiencies  can  be  overcome  and  avoided 
if  the  problem  is  recognized  and  addressed  by  management  in  the  early 
phases  of  the  acquisition  program.  The  acquisition  strategy  must  pro¬ 
vide  for  reliability  and  maintainability  R&M)  engineering  support  as  an 
integral  part  of  system  engineering  and  equipment  design.  It  must  also 
provide  for  frequent  assessment  of  the  program's  reliability,  maintain¬ 
ability  and  availability  (RM&A)  capabilities. 

RELIABILITY  is  defined  as  the  duration  or  probability  of  failure- 
free  performance  under  given  conditions,  and  is  usually  expressed  as 
mean-time-between-failure  ( MTBF ) .  Numerous  methods  can  be  found  for 
specifying  reliability;  however,  they  all  boil  down  to  the  degree  of 
dependability  of  a  given  item.  Reliability  is  a  design  attribute.  It 
either  is  or  is  not  designed  into  the  equipment  and  cannot  be  improved 
per  se  either  by  testing  or  by  the  actions  of  logisticians  or  support 
personnel,  although  it  can  be  improved  through  TAAF  procedures. 

MAINTAINABILITY  is  defined  as  the  ability  of  an  item  to  be  retained 
in  or  restored  to  a  specific  condition  when  maintenance  is  performed  by 
personnel  having  specified  skill  levels,  using  prescribed  procedures  and 
resources,  at  each  prescribed  level  of  maintenance  and  repair.  Main¬ 
tainability  can  be  expressed  in  a  number  of  ways,  the  most  common  being 
mean-time-to-repair  (MTTR)  and  maintenance  man-hours  per  operating  hour. 

AVAILABILITY  is  defined  as  the  probability  that  a  system  or  compo¬ 
nent  is  in  an  operable  state  at  the  start  of  a  mission  called  for  at  an 
unknown  (random]  time.  Availability  is  a  function  of  reliability, 
maintainability,  and  fleet  support  and  is  maximized  by  balanced  trade¬ 
offs  of  these  parameters  during  the  design  and  development  process. 

Operational  Availability  (Ao)  is  an  index  of  weapon  system  material 
readiness,  including  system  software  where  applicable,  in  a  mission 
environment.  It  does  not  attempt  to  capture  personnel  readiness  nor  the 
probability  of  mission  success.  It  is  instead  a  measure  of  the  proba¬ 
bility  of  an  item  being  in  a  condition,  generally  referred  to  as  "up", 
such  that  it  can  perform  its  intended  function,  within  acceptable  limits 
of  degradation,  when  called  upon. 

The  readiness  of  a  system  or  equipment  to  perform  an  intended 
function  is  influenced  by  its:  RELIABILITY  -  the  duration  or  probability 
of  failure-free  performance  under  stated  conditions;  MAINTAINABILITY  - 
the  extent  to  which  the  item  can  be  retained  in,  or  restored  to,  an  up 
condition  when  maintenance  is  performed  by  personnel  having  specified 
skill  levels,  using  prescribed  procedures  and  resources,  at  each  pre¬ 
scribed  level  of  maintenance  and  repair;  and  SUPPORTABILITY  -  the  degree 
to  which  the  above-mentioned  personnel,  training  and  resources  (especi¬ 
ally  spare  parts)  are  in  place  so  as  to  minimize  logistics-related 
delays  within  the  maintenance  processes. 

Thus,  in  addition  to  being  an  important  characteristic  in  its  own 
right,  Ao  can  be  thought  of  as  a  vehicle  for  consolidating  the  combined 
and  interdependent  effects  of  reliability,  maintainability  and  supporta- 
bility. 


4-59 


R&M  must  be  uppermost  in  the  minds  of  people  at  all  levels  and  in 
all  functional  areas  of  acquisition  management.  The  pursuit  of  R&M  is 
more  a  disciplined  approach  to  the  acquisition  process  than  it  is  a 
particular  set  of  practices  and  procedures.  Figure  4-14  indicates  the 
major  interdisciplinary  interfaces  of  integrated  R&M  programs. 


FIGURE  4-14.  R&M  Interdisciplinary  Interfaces, 


The  goal  of  R&M  efforts  is,  of  course,  availability.  Because 
products  that  are  substantially  more  reliable  will  diminish  the  need  for 
maintenance,  reliability  becomes  a  very  important  design  attribute.  The 
reliability  of  a  system  depends  on  its  design.  The  technical  design 
team  must  know  the  environmental  conditions  in  which  the  system  will 
operate  (levels  of  temperature,  vibration,  shock,  humidity,  salt-fog/ 
spray,  altitude,  etc.)  and  the  length  of  time  in  each;  this  information 
is  included  in  the  mission  profile  (see  MI L-STD-1 470) .  Beginning  as 
early  as  the  Concept  Exploration  Phase,  the  emphasis  should  be  on  sim¬ 
plicity  in  the  design  for  these  conditions,  keeping  to  a  minimum  the  use 
of  high-risk  advance  concepts  and  parts  whose  reliability  track  records 
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lack  the  test  of  time.  To  maximize  the  likelihood  of  achieving  high 
reliability,  the  allocation  of  an  overall  numerical  reliability  value  to 
each  of  the  system's  subassemblies,  as  well  as  the  predictions  support¬ 
ing  design  trade-off  decisions,  must  reflect  the  complexity,  criticality 
and  technological  risk  in  each  subassembly. 

The  selection  and  application  of  parts  and  materials  play  a  signi¬ 
ficant  role  in  reliability  achievement.  A  parts  control  program  - 
including  parts  derating  -  is  essential  to  establish  and  maintain  (1) 
qualified  parts  lists,  (2)  specification  control  drawings  for  parts 
procurement  from  approved  sources,  and  (3)  laboratory  facilities  for 
testing  and  screening  parts  and  materials. 

A  comprehensive  program  of  development  test  and  evaluation  (DT&E) 
and  operational  test  and  evaluation  (OT&E)  is  essential  for  the  attain¬ 
ment  of  RM&A  goals.  The  purpose  of  testing  is  to  determine  whether  or 
not  the  emerging  design  meets  the  stated  performance  requirements, 
including  R&M.  Any  shortfall  must  stimulate  redesign  until  the  require¬ 
ments  are  met  or  other  compensatory  action  taken. 

Once  production  commences,  quality  control  becomes  the  key  factor 
in  assuring  that  the  reliability  inherent  in  the  final  design  is  not 
degraded  by  the  manufacturing  process.  A  manufacturing  screening  pro¬ 
gram  should  be  initiated  in  accordance  with  NAVMAT  P-9492.  A  failure 
analysis  should  proceed  any  corrective  action  taken  to  alleviate  the 
adverse  effects  of  marginal  manufacturing  processes  or  to  enhance  pro¬ 
ductivity. 

Good  contracting  is  one  of  the  keys  to  an  effective  RM&A  program. 
It  is  often  assumed  that  reliable  and  maintainable  products  will  result 
from  requiring  a  contractor  to  formulate  and  conduct  a  reliability  and 
maintainability  program  in  accordance  with  appropriate  military  stan¬ 
dards.  However,  the  contractor  cannot  be  expected  to  offer  better  R&M 
characteristics  than  the  specification  requires,  since  he  would  thereby 
risk  loss  of  the  contract  to  a  lower  bidder.  The  PM,  with  the  assis¬ 
tance  of  the  procurement  team,  should  ensure  that  the  R&M  requirements 
are  quantitatively  stated  in  the  solicitations  and  in  the  negotiated 
contracts,  that  they  are  realistic  and  achievable  and  more  importantly, 
that  the  equipment  design  exhibits  the  specified  R&M  characteristics 
before  it  is  accepted  for  Naval  service.  Figure  4-15  indicates  a  time- 
phase  breakout  of  the  principal  R&M  related  tasks. 

For  further  information  on  R&M,  the  PM  should  consult  DODD  5000.40, 
SECNAVINST  3900.36,  0PNAVINST  3960.10,  N4VMATINST  3000.1  and  3900.13  and 
MIL-STD-756,  -785  and  -470. 


QUALITY 

Quality  is  the  composite  of  desirable  material  attributes,  includ¬ 
ing  performance  and  must  be  designed  into  the  product  during  its  devel¬ 
opment  phases.  It  will  never  be  realized,  however,  if  there  is  not  also 
a  strong  quality  assurance  program  that  mandates  a  rigorously  conceived 
and  practiced  quality  control  program. 
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FIGURE  4-15.  Time  Phase  Breakout  of  Principal  R&M  Related  Tasks. 


Quality  Control  (QC) 

The  QC  program  must  ensure  that  the  product  to  be  delivered  does  in 
fact  uniformly  meet  or  exhibit  the  quantitatively  and  qualitatively 
expressed  performance  and  compatibility  requirements  and  other  quality 
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(design)  attributes  required  under  the  contract. 


Quality  Assurance  (QA? 

QA  ->s  the  planned  and  systematic  pattern  of  all  actions  necessary 
to  provide  adequate  confidence  that  material,  data,  supplies,  and  ser¬ 
vices  conform  to  established  technical  requirements  and  achieve  satis¬ 
factory  performance.  QC  is  the  management  function  that  controls  the 
quality  of  raw  or  produced  material  exercised  for  the  purpose  of  pre¬ 
venting  the  production  of  defective  material. 

The  major  contributors  to  the  depressed  quality  of  the  hardware, 
software,  and  technical  data  reaching  the  fleet  are  (1)  the  lack  of  QC 
in  the  processes  and  procedures  by  which  military  products  are  developed 
and  produced,  and  (2)  the  failure  to  establish  and  enforce  meaningful  QA 
programs  for  the  detection  of  and  early  remedial  action  on  breakdowns  in 
the  area  of  QC. 


Quality  Management 

Obviously  the  program  team,  including  the  contractors,  readily 
subscribes  to  and  strives  for  the  goal  of  development,  test,  and  accep¬ 
tance  of  a  quality  product  and,  generally  speaking,  is  at  least  moder¬ 
ately  successful  in  achieving  that  goal  if  given  enough  time  and  resour¬ 
ces.  What  is  not  so  obvious  is  that  all  hands  must  be  equally  dedicated 
to  the  policing  operation  that  needs  to  be  mounted  and  continued  with 
dedication  and  vigor,  if  the  quality  attributes  of  which  the  design  is 
capable  are  to  be  consistently  exhibited  by  the  product  presented  by  the 
contractor  for  acceptance. 

When  the  PM  seeks  adequate  confidence  that  the  delivered  product  is 
a  quality  product,  that  confidence  can  be  derived  from  only  two  sources. 
One  is  the  confidence  gained  when  the  product  is  observed  to  perform 
properly  when  subjected  to  the  prescribed  production  acceptance  tests. 
The  other,  py  far  the  most  important,  is  the  confidence  gained  when  one 
knows  that  the  materials  used,  the  workmanship  going  into,  and  the 
processes,  procedures,  and  in-process  tests  employed  in  the  fabrication 
and  delivery  of  the  product  were  as  prescribed  for  every  item  being 
delivered.  If  that  confidence  is  to  be  gained,  and  if  the  Fleet  inven¬ 
tory  is  not  to  be  contaminated  by  faulty  equipment,  the  control  of 
quality  going  into  the  design  in  the  first  place  and  the  practice  of 
rigorous  and  continuing  QC  in  product  manufacture  are  essential. 

The  PM  is  required  by  DODD  5000.1  and  SECNAVINST  5000.1  to  ensure 
that  complete  and  realistic  QA  and  QC  requirements  are  incorporated  in 
the  mission  need  decision  (MND),  and  in  contract  documents  (solicita¬ 
tions,  contracts,  and  change  orders).  He  must  also  establish  necessary 
quality  data  collection,  reduction,  feedback,  and  corrective  action 
requirements,  and  an  adequate  OCAS  evaluation  of  contractor  QA/QC  pro¬ 
grams  (SECNAVINST  4355,14).  The  PM  must  also  ensure  that  consideration 
is  given  to  quality  requirements,  quality  history,  and  capabilities  by 
source  selection  boards. 


The  PM  is  also  responsible,  through  his  functional  support  team, 
for  reviewing  contractor  QA/QC  programs  to  ensure  that  all  essential 
actions  related  to  product  quality  are  being  pursued  in  an  organized  and 
acceptable  manner.  He  will  address  QA/QC  requirements,  plans,  achieve¬ 
ments  at  the  appropriate  milestone  decision  review  point. 


Quality  Frogram  Assistance 

It  is  easier  and  less  expensive  to  demand  and  get  good  QC  in  the 
development  and  fabrication  of  a  product  than  it  is  to  redevelop  the 
item  or  to  purge  an  inventory  that  has  been  contaminated.  Like  many 
other  activities  that  involve  recurring  actions,  the  tendency  is  to 
relax  when  things  are  going  well  or  even  to  loosen  the  controls  that 
have  caused  things  to  go  well.  This  is  one  of  the  many  time  when  a 
knowledgeable  in-house  laboratory  or  center  that  has  been  intimately 
involved  with  the  evaluation  of  the  product  can  perform  a  useful  service 
by  helping  to  develop  a  good  QA/QC  program  and  assist  local  DCAS  imple¬ 
mentation  of  it.  The  PM  should  enlist  the  service  of  a  knowledge¬ 
able  government  activity  such  as  a  Navy  laboratory  to  render  assistance 
in  quality  management.  Enlisting  the  service  of  an  independent  Navy 
laboratory  or  center  to  audit  the  performance  of  contractors,  DCAS/PRO, 
and  test  activities  might  seem  to  be  overkill;  however,  the  importance 
of  ensuring  the  delivery  of  a  high-quality  product  with  minimum  latent 
defects  into  the  service  inventory  is  ample  justification.  Delivery  of 
inferior  products  not  only  lays  the  groundwork  for  expensive  and  time- 
consuming  inventory  purging  and  rework  programs,  but  robs  the  using 
commanders  of  their  operational  capability.  QC  must  be  practiced  rigor¬ 
ously  and  on  a  continuing  basis  if  gradual  and,  perhaps,  catastrophic 
quality  deterioration  of  the  product  is  to  be  avoided. 

SECNAVIN5T  4355,14,  Quality  Assurance,  is  implemented  by  NAVMATINST 
4855.1.  These  two  instruction  together  with  MIL-5TD  109  establish  Navy 
policies  for  QA  programs,  PMs  are  encouraged  to  designate  a  project 
support  officer  for  QA  who  will  structure  and  implement  a  QA  program 
tailored  to  meet  the  needs  of  his  particular  acquisition  program. 


LOGISTIC  SUPP0RTAB1 L ITY 

To  those  responsible  for  the  operation  of  military  systems  and 
equipment,  it  has  become  increasingly  obvious  that  a  major  limiting 
factor  in  their  operational  capability  and  availability  is  logistic 
support.  Operational  commanders  carefully  watch  the  statistics  on  those 
items  of  equipment  that  are  nof  operationally  ready  because  or  mainten¬ 
ance  or  supply  difficulties.  They  have  come  to  recognize  the  importance 
of  having  an  adequate  supply  of  spare  parts,  test  and  support  equipment, 
and  a  sufficient  number  of  trained  personnel  to  operate  and  maintain  the 
system.  In  short,  they  have  come  to  recor^ize  the  importance  of  inte¬ 
grated  logistics  support  (ILS), 

The  achievement  cf  logistic  supportabi 1 ity  necessitates  that  all 
support  requirements  be  considered,  planned,  and  budgeted  for  from  the 
beginning  of  the  development  process.  DODD  5000.1  requires  that  "Logis¬ 
tic  supportabi 1 ity  shall  be  a  design  requirement  as  important  as  c  st. 
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schedule,  and  performance.  A  continuous  interface  between  the  PMO  and 
the  manpower  and  logistics  communities  shall  be  maintained  throughout 
the  acquisition  process".  This  amplified  by  SECNAV1NST  5000.1,  which 
requires  that  each  program  charter  include  the  designation  of  a  logis¬ 
tics  manager  to  assist  the  PM. 

One  of  the  major  duties  of  the  logistics  manager,  in  conjunction 
with  the  PM,  is  to  develop  and  update  an  ILS  Plan  (ILSP).  The  ILSP 
provides  a  framework  for  organizing  and  managing  the  resources  and 
activities  which  will  culminate  in  efficient,  cost-effective  Fleet  sup¬ 
port  for  the  system  under  development.  The  ILSP  reduces  uncertainty  in 
support  planning,  ensures  compatibility  of  resources,  and  diminishes  the 
duplication  of  effort. 

Integration  is  the  key  to  good  support  planning.  ILS  is  a  techni¬ 
que  for  designing  the  support  concurrent  with  the  system  design  so  that 
ILS  options  and  trade-offs  can  be  considered  before  the  design  is  fro¬ 
zen,  and  the  optimum  balance  of  logistic  support  elements  can  be  achiev¬ 
ed.  The  principal  ILS  elements  include: 

1.  Maintenance  planing 

2.  Manpower  and  personnel 

3.  Supply  support 

4.  Support  equipment 

5.  Technical  data 

6.  Training  and  training  support 

7.  Computer  resources  support 

8.  Facilities 

9.  Packaging,  handling,  storage  and  transportation 

10.  Design  interface 

The  elements  of  ILS  are  planned  simultaneously  during  the  develop¬ 
ment  phases  of  a  program.  The  maintenance  plan  is  the  lead  document 
because  the  concept  of  maintaining  the  system  affects  the  planning  of 
all  the  other  elements.  For  example,  technical  manuals  must  be  consis¬ 
tent  with  the  levels  of  repair  defined  in  the  maintenance  plan,  and 
training  schedules  for  maintenance  personnel  must  be  coordinated  so  that 
the  correct  number  of  personnel  with  the  required  skills  is  available 
when  the  system  is  introduced  into  the  Fleet. 

The  ILS  elements  are  to  be  merged  into  the  Ti  SP  through  logistic 
support  analysis  (ISA),  which  includes  "the  use  of  appropriate  analyti¬ 
cal  tools  and  models  throughout  the  acquisition  cycle  to  evaluate  alter¬ 
native  support  concepts,  to  perform  trade-offs  between  system  design  and 
ILS  elements,  and  to  perform  trade-offs  among  ILS  elements  in  order  to 
meet  system  readiness  objectives  at  minimum  cost".  (DODD  5000.39). 

These  trade-offs  must  be  made  early  in  the  acquisition  process, 
when  the  system  is  relatively  undefined.  Supportabi 1 ity  should  be  an 
important  factor  in  the  contractor's  choice  of  design,  and  support 
requirements  should  be  included  in  the  design  specifications.  Design 
details  with  significant  support  impact  can  extend  the  life  of  the 
equipment,  reduce  maintenance  time  and  cost,  increase  system  availabili¬ 
ty.  and  reduce  supply  cost  oven  the  system's  life  cycle. 


4-65 


The  support  problems  to  be  dealt  with  will  vary  according  to  the 
complexity  and  operational  characteristics  of  the  system.  The  logistics 
functions  must  be  tailored  to  each  acquisition.  A  listing  of  t LS  con¬ 
siderations,  broken  down  by  milestones,  is  set  out  as  enclosure  (3)  to 
DODD  5000.39. 

There  are  many  related  disciplines  and  activities  which  are  not 
considered  I LS  elements  but  which  ultimately  have  an  influence  on  sup¬ 
port.  Reliability,  maintainability,  human  factors  engineering,  safety, 
data  management,  and  configuration  management  are  some  of  these. 

Prior  to  Milestones  I,  II,  and  III  for  ACAT  I  and  II  programs  and 
selected  ACAT  III  and  IV  programs,  a  Logistics  Review  Group  ( LRG )  headed 
by  the  Deputy  Chief  of  Naval  Material  for  Logistics  (DCNM(L))  will 
review  the  program's  ILS  program  and  assess  its  adequacy.  This  will 
include  an  assessment  of  the  planning  for  ILS  management,  analysis, 
resources,  scheduling,  contract  structure,  and  budget,  relative  to  the 
program  objectives.  The  LRG  will  report  to  the  Chief  of  Naval  Material 
(CNM)  who  will  certify  the  ILS  program  prior  to  commitment  of  additional 
resources  or  new  contractual  commitments  for  the  acquisition  of  mate¬ 
rial.  For  ACAT  III  and  IV  programs  not  selected  for  CNM  review,  ILS 
assessment  and  certification  is  accomplished  by  a  SYSCOM  LRG.  Enclosure 
(3)  of  NAVMATINST  4105.3  contains  a  list  of  the  ILS  certification  fac¬ 
tors. 


Further  assistance  in  implementing  logistic  support  for  an  acquisi¬ 
tion  program  may  be  obtained  from  MAT-043,  NAVAIR-401,  NAVELEX-811 , 
NAVSEA-90L,  the  principal  (lead)  field  activity  or  the  Naval  Weapons 
Engineering  Support  Activity,  Washington  Navy  Yard. 


MANPOWER,  PERSONNEL  AND  TRAINING 

The  DON  continues  to  experience  serious  problems  in  the  supply  of 
adequate  numbers  of  skilled  personnel  for  operating  and  maintaining 
weapon  systems.  The  identification  of  manpower  and  training  support  has 
typically  come  as  an  afterthought  in  the  acquisition  process.  As  a 
result,  the  Naval  Military  Personnel  Command  (NMPC)  which  is  responsible 
for  manning  systems  with  skilled  personnel,  has  been  operating  in  a 
reactive  mode,  responding  as  best  it  can  to  requirements  thrust  upon  it 
by  system  entering  the  Fleet. 

Manpower  costs  have  increased  rapidly  in  recent  years,  and  now 
account  for  approximately  5b%  of  a  ship's  annual  operating  expenses. 
Manpower  has  become  the  single  most  expensive  element  in  the  Navy's 
inventory  and  is  a  major  determinant  of  system  LCC.  Since  up  to  70%  of 
system  LCC  are  determined  by  decisions  made  during  the  Concept  Explora¬ 
tion  Phase,  the  PM  and  his  staff  must  consider  the  impact  that  their 
decisions  will  have  on  human  resources. 


Humon  resources  and  the  hardware/man  interface  are  major  determ- 
inants  of  a  system's  operational  effectiveness.  In  sDite  of  this,  they 
have  been  given  little  or  no  consideration  during  the  early  design 
phases  of  most  Navy  systems.  System  design  engineers  have  made  their 
decisions  based  almost  completely  on  the  trade-off  of  schedule  and 
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performance  considerations,  and  today  this  is  neither  working  nor  is  it 
affordable.  Manpower  and  training  support  requirement  must  be  consider¬ 
ed  as  design  trade-off  variables.  Figure  4-16  shows  the  manpower, 
personnel,  and  training  support  (MP&TS )  planning  input  requirements  by 
phases  in  the  acquisition  process. 

Shifting  manpower,  personnel,  and  training  emphasis  into  the  design 
arena  places  the  responsibility  for  its  early  consideration  squarely  in 
the  hands  of  the  PM-system  designers  and  the  development  agency.  Cur¬ 
rent  000  and  DON  policy  clearly  reflect  this  fact.  Manpower,  personnel, 
and  training  requirements  analyses  must  be  made  early  in  the  acquisition 


MAJOR  ROT&E 

CONCEPT 

DEMONSTRATION 

FULL-SCALE 

(ENGINEERING) 

DEVELOPMENT 

PRODUCTION/ 

PROGRAM  PHASES 

EXPLORATION 

ANO  VALIDATION 

DEPLOYMENT 

program  INITIATION  MILESTONE  MILESTONE  MILESTONE  I 

PRIMARY 

i 

:  ic 

0ECISI0N 

POINTS 

MP&TS  CONCEPT 

DRAFT  NAVY  TRAINING 

PRELIMINARY  SHIP  MAN- 

UPDATE  AND  REPINE  SMO/ 

PLAN  (NTP) 

POWER  DOCUMENT  (SMO) 

SMI 

ANALYSES  OF  MAN/MACHINE 

OR  INFORMATION  (SMI) 

FUNCTIONS 

MP&TS  INPUT  TO  INTE- 

OR  PRELIMINARY  SQUAD- 

UPOATE  ANO  REFINE  NTP 

GRATED  LOGISTIC  SUPPORT 

RON  MANPOWER  DOCU- 

MP&TS  INPUT  TO  FUNC- 

II  LSI  RIAN 

MENT  ISQMD) 

REFINE  MP&TS  SECTION 

TIQNAL  IMPLEMENTATION 
PLAN 

MR&TS  INRUT  TO  REQUESTS 

NAVY  TRAINING  PLAN 

TO  ILS  PLAN 

FOR  PROPOSAL  IflFP) 

CONFERENCE 

MP&TS  EVALUATION  CRI 

PRELIMINARY  MANNING  ESTI¬ 
MATES  FOR  EQUIPMENT/ 

TRADEOFF  STUOIES  FOR 

UPOATE  NTP 

TERIA  FOR  FOT&E 

SYSTEMS 

EQUIPMENT/SYSTEMS 

MONITOR  AND  EVALUATE 

MANPOWER, 

DRAFT  CREW  PHASING 

CONTRACTOR  MP&TS 

PERSONNEL. 

TRADEOFF  STUDIES  FOR 

PRELIMINARY  SHIR/SQUAD- 

ANO  SCHEDULING  PLAN 

ANO 

EQUIPMENT/SYSTEMS 

RON  MANNING  DOCUMENT 

FINALIZING  CREW  PIIAS 

TRAINING 

(PSUD/PSQMD) 

NEW  NEC  REQUIREMENTS 

INC  AND  SCHEDULING 

CONSIDERATIONS 

IN  JMSNS/ORJROC 

UPDATE  MP&TS  SECTION 

TO  ILS  PLAN 

FLAN 

POM  MANPOWER  INPUT  FOR 
IQT&E,  TECHEVAUQPEVAL, 
AND  TO  SUPPORT  FLEET 
DELIVERIES 

DEVELOP  MP&TS  CONTRAC¬ 
TOR  EVALUATION  CRI¬ 
TERIA 

MONITOR  ANO  IDENTIFY 

MONITOR  ANO  IDENTIFY 

MONITOR  An  li  IDENTIFY 

MONITOn  AND  IDENTIFY 

MP&TS  PROBLEM  AREAS 

MP&TS  PROBLEM  AREAS 

MP&TS  PROBLEM  AREAS 

MP&TS  PROBLEM  AREAS 

FIGURE  4-16.  MP&TS  Requirements  in  the  Acquisition  Process.* 

*  Typical  products/actions.  Specific  outputs  and  time  phasing 
may  vary  as  mutually  agreed.  From  NAVSEAINST  5311.1,  June 
1977. 

process,  with  increasing  detail  required  in  successive  phases.  DODI 
5000.2  requires  that: 

i:New  systems  shall  be  designed  to  minimize  manpower  (number, 
grades,  specialty,  and  skill  levels)  needed.  Service  studies 
projecting  personnel  skill  level  availability  to  meet  manpower 
requirements  shall  be  included  at  program  initiation  as  con¬ 
straints  in  system  design  and  shall  be  integrated  with  human 
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engineering  design  criteria  to  form  the  basis  on  initial 
operating  and  support  concept  studies  and  refined  as  system 
development  progresses,  to  form  the  basis  for  crew  station  and 
maintenance  design  as  well  as  personnel  and  training  require¬ 
ments,  training  devices  and  simulator  design,  and  other  plan¬ 
ning  related  to  manpower  and  personnel.  Goals  and  thresholds 
for  manpower  number  and  skill  levels  shall  be  established  and 
evaluated  in  T&E.  Plans  for  training  shall  consider  trade¬ 
offs  conducted  among  job  aids,  formal  training,  on-the-job 
training,  unit  training,  and  training  simulators.  Each  pro¬ 
gram  shall  develop  a  cost-effective  plan  for  attaining  and 
maintaining  the  personnel  proficiency  needed  to  meet  wartime 
mission  objectives.  Such  planning  shall  consider  provisions 
for  unit  conversion  to  the  field  system  and  training  of  re¬ 
serve  component  personnel". 

Designing  in  Relation  to  Human  Resources.  The  primary  factor 
driving  all  manpower  costs  are  the  number,  complexity,  and  frequency  of 
operator  and  maintainer  tasks.  These  factors  determine: 

1.  Tne  number  of  maintenance  and  operator  personnel  required. 

2.  The  required  aptitude  levels  of  these  personnel. 

3.  The  experience  levels  required  to  perform  satisfactorily. 

4.  The  amount  of  general  and  specialized  training  required. 

Various  system  design  concepts  have  more  or  less  impact  on  the 
complexity  of  operator  and  maintainer  tasks.  The  manpower-and-training 
cost  consequences  of  these  concepts  must  be  traded  off  against  other 
cost-benefit  consideration  beginning  in  the  Concept  Exploration  Phase. 

The  manpower  development  process  includes  optimizing  the  manpower 
requirements  for  the  system  under  development,  establishing  the  operator 
requirements  for  various  states  of  readiness,  assessing  all  maintenance 
requirements,  establishing  total  administrative  and  support  workloads, 
taking  into  account  the  time  required  for  irregular  and  utility  tasks, 
and  making  allowances  for  average  productivity  levels. 

Though  the  system  designer  cannot  control  all  of  these  factors,  it 
is  important  for  him  to  be  responsive  to  overall  manning  problems  and 
the  availability  of  personnel,  and  to  be  aware  of  the  many  variables 
that  he  does  impact  in  the  overall  manning  equation.  These  variables 
include: 

1.  Operator  requirements 

2.  Preventive  and  corrective  maintenance  requirements 

3.  Training  and  service  diversion  requirements 

4.  Rate/rank  and  skill  requirements 

5.  Cross-utilization  of  personnel  for  various  conditions  of  rea¬ 
diness 

6.  Administrative  and  support  workload 

7.  Utility  (miscellaneous  task  and  evolution)  requirements 

8.  Facilities  maintenance  (cleaning,  painting,  etc.) 

9.  Productivity  allowance  factors 

10.  The  standard  work  week  as  stipulated  by  the  CNO. 
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The  design  engineer  directly  influences  items  1,  2,  3,  4,  and  5 
through  the  election  of  design  alternatives.  In  addition,  minimizing 
the  number  of  system  personnel  can  indirectly  affect  items  6  and  7.  On 
shipborne  systems,  important  secondary  savings  car.  result  from  decreased 
requirements  for  onboard  service  and  administrative  personnel.  These 
savings  can  come  about  either  through  a  reduction  of  the  absolute  number 
of  operation  and  maintenance  personnel  on  board,  or  by  transferring  a 
greater  portion  of  the  support  and  administrative  burden  to  tender  or 
shore-based  facilities.  Since  support  and  administrative  personnel 
constitute  20-25%  of  a  typical  ship's  crew,  these  additional  indirect 
savings  can  be  substantial. 

Training  Aids.  The  PM  should  consider  the  development  of  training 
aios  and  other  ancillary  equipment,  such  as  training  manuals  and  simula¬ 
tor,  to  support  his  finished  acquisition.  The  use  cf  training  aids  and 
simulators  has  become  more  and  more  important  as  the  complexities  of 
systems  have  increased  and  the  cost  of  expendables  such  as  missiles  and 
projectiles,  ?s  well  as  the  cost  of  ship  steaming  days  or  aircraft 
flight  hours,  have  increased.  Where  once  it  was  practical  and  efficient 
to  develop  bomb  delivery  accuracy  or  gunnery  efficiency  by  practicing 
with  live  or  dummy  ammunition,  it  is  now  prohibitively  expensive  to  do 
sc.  Yet  it  is  still  essential  that  personnel  gain  experience  in  the  use 
of  modern  equipment  and  learn  to  overcome  conditions  such  as  electronic 
countermeasures  (ECM)  that  are  encountered  in  wartime.  One  means  of 
obtaining  realistic  training  is  the  use  of  system  simulators  and  sophis¬ 
ticated  training  devices  that  provide  feedback  on  operator  effectiveness 
and  performance.  Such  devices  must  be  as  carefully  developed  as  the 
real  system  to  provide  the  maximum  benefit  of  training  and  to  ensure 
that  the  simulated  conditions  and  operations  match  the  operational 
environment  closely.  Tbo  development  of  such  "trainers"  must  proceed  at 
the  same  pace  os  that  of  the  final  system. 

Obtaining  Assistance.  The  Navy  has  recognized  the  importance  of 
minimizing  manpower ,  personnel  and  training  costs  and  is  implementing  a 
Navy-wide  effort  to  achieve  this  goal.  As  a  result,  it  should  be  pos¬ 
sible  for  the  PM  to  obtain  general  advice  and  guidance  from  OPNAV  01, 
and  particularly  from  the  HARDMAN  (Military  Manpower/Hardware  Integra¬ 
tion)  Development  Section  (0p-l 1  ICO;  from  specialists  in  manpower,  per¬ 
sonnel,  and  training  within  his  own  SYSCOM;  ana  from  the  Naval  Personnel 
Research  and  Development  Center  (NPRDC),  San  Diego.  The  HARDMAN  Section 
has  developed  and  tested  methodologies  for  determining  manpower  rsquire- 
ments  and  training  requirements  in  addition  to  developing  and  testing  a 
series  of  LCC  models.  The  metnonologies  and  models  are  designed  to  be 
applied  throughout  the  weapon  system  acquisition  program  by  the  PM  and 
his  staff  in  order  to  determine  the  manpower,  personnel,  and  training 
implications  of  Ms  program.  NPRDC  has  been  developing  "An  Engineers 
Guide  to  the  Use  of  Human  Resources  in  Electronic  Systems  Design"  (NPRDC 
TN  79-8)  as  well  as  instructional  material  in  related  areas.  Tha  NMPC 
5/6,  can  also  provide  assistance.  The  Naval  Education  and  Training 
Program  Development  Center,  Pensacola,  and  the  Naval  Training  Equipment 
Center,  Orlando,  have  proven  helpful  in  the  past  on  questions  of  train¬ 
ing  and  training  equipment.. 
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EMBEDDED  COMPUTER  RESOURCES 


The  combat  launch  of  an  aircraft  without  its  missiles  or  the  sortie 
of  a  submarine  without  its  torpedoes  makes  successful  destruction  cf 
enemy  forces  highly  unlikely.  To  any  professional,  this  fact  is  obvi¬ 
ous;  ordnancemen,  commanders,  and  deck  seamen  all  agree.  Far  fewer, 
however,  know  that  weapon  systems  with  full  armament  installed  may  be 
equally  failure-prone  because  of  embedded  computer  resource  (ECR)  defi¬ 
ciencies.  In  the  age-old  evolution  or  the  science  of  warfare,  it  will 
take  more  time  to  establish  that  dropping  a  computer  "bit"  in  today's 
dog  fight  is  just  as  serious  as  was  a  caveman  dropping  his  club  in 
battle. 

PMs  universally  have  become  aware  that  we  can  no  longer  fly,  dive, 
steam,  or  fight  without  ECRs  in  most  of  our  weapon  systems.  We  use  ECRs 
to  make  our  systems  operate,  to  test  them,  to  produce  them,  to  adapt 
them,  and  to  keep  them  responsive  to  changing  threats.  Software  can 
confer  many  of  the  “llities"  on  a  system  -  changeability,  flexibility, 
capability,  versatility,  even  affordabi lity,  to  name  a  few.  ECRs  can 
make  the  same  airframe  usable  and  effective  in  a  fighter  or  an  attack 
role  and  theoretically  reduce  the  number  of  airframes  needed  to  perform 
the  combined  tasks,  provided  the  tasks  are  performed  sequentially  and 
not  concurrently.  There  is  seemingly  an  endless  number  of  benefits  to 
be  gained  through  the  increased  use  of  ECRs. 

There  also  can  be  a  nightmare  of  system  performance  failure,  cost 
overrun,  schedule  slippage,  and  even  loss  of  program  control  awaiting 
the  PM  who  does  not  manage  software  development  with  the  skill  and  to 
the  same  extent  that  he  manages  hardware  development.  Equal  emphasis  on 
software  and  hardware  should  apply  from  the  beginning.  The  ECR  must  be 
evaluated  as  to  its  supportabi lity:  common  high  order  language,  availa¬ 
bility  of  compilers,  transportability  of  coding,  documentation  deliver¬ 
ables,  etc.  Universal  test  equipment  availability  for  the  hardware  and 
for  the  software  are  features  which  should  also  be  evaluated.  In  short, 
system  software  should  be  treated  as  a  vitally  important  configuration 
item  just  as  much  as  is  the  engine  in  an  aircraft  weapon  system  selected 
for  development. 

System  software  management  tools  and  techniques  have  matured  in 
recent  years.  Standards  and  specifications  have  been  produced.  These 
are  now  beginning  to  be  used  in  software  develooment  in  much  the  same 
way  that  MIL-SPECs  have  long  been  usea  in  the  hardware  development 
field.  Instructions  exist  which  establish  a  minimum  set  of  required 
documentation  to  dc  produced  as  part  of  system  software  development. 

The  defense  management  policy  for  mission  essential  ECRs  is  articu¬ 
lated  in  DOCD  5000.29,  Management  of  Computer  Resources  in  Major  Defense 
Systems,  which  established  a  Management  Steering  Committee  for  Embedded 
Computer  Resources  to  provide  appropriate  oversight;  DODI  5000  31,  Inte¬ 
rim  List  of  D0D  Approved  High  0> der  Programming  Languages  (H0L);  and  in 
the  proposed  DODI  5000. 5X,  Instruction  Set  Architecture  (ISA)  Standardi¬ 
zation  Policy  for  Embedded  Computers. 

These  policies  and  instructions,  if  understood  and  heeded  by  both 
industry  and  the  Navy  PMs,  will  assure  contractor’s  resr.-insivenrss  to 
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the  Navy’S  requirements.  Policies  have  been  developed  and  promulgated 
in  the  broad  area  of  system  software  development  and  support  (see  SEC- 
NAVINSY  3560,,'!).  NAVMAT  policy,  for  example,  requires  the  use  of  Navy 
standard  higher  order  languages  such  as  Ada,  CMS-2  and  SPL-1.  Policy 
documents  in  this  regard  are  called  Tactical  Digital  Standards  (TAD- 
STAND)  and  are  promulgated  by  the  Tactical  Embedded  Computer  Program 
Office  (TECPO),  (MAT--08Y).  There  are  five  TADSTANDs,  designated  A-8. 
They  deal  with  standard  definitions  for  ECRs  in  tactical  digital  sys¬ 
tems;  standard  embedded  computers,  computer  peripherals,  and  input/out¬ 
put  interfaces;  computer  programming  language  standardization  policy  for 
tactical  digital  systems;  reserve  capacity  requirements  for  tactical 
digital  systems;  and  software  development  documentation  and  testing 
policy  for  Navy  mission  critical  systems. 

Navy  policies  include  the  requirement  to  transition  system  software 
support  from  the  developing  contractor  to  another  agency  at  an  appropri¬ 
ate  time.  This  transition  is  usually  to  a  designated  Navy  facility 
where  an  in-house  software  support  activity  is  established. 

Software  management  has  been  recognized  by  successful  PMs  as  re¬ 
quiring  early,  intensive,  continuing  management.  There  is  no  program 
phase  that  is  too  early  for  concern  with  software.  In  fact  if  the 
software  standards  to  be  utilized  are  not  identified  as  early  as  issu¬ 
ance  of  the  system  solicitation,  some  from  of  disaster  is  highly  prob¬ 
able.  Hardware  development  that  is  allowed  to  proceed  in  advance  of 
software  decisions  will  generally  constrain  system  design.  Program 
decisions  in  gocd  designs  are  made  with  engineering  balance  hardware  and 
software  considerations. 

PMs  are  enjoined  in  D0D-STD-1679A  to:  (1)  make  extraordinary  ef¬ 
forts  in  the  development  phase  to  ensure  maximum  reliability  and  main¬ 
tainability  of  software;  (2)  ensure  software  is  designed  to  facilitate 
efficient  change  (even  at  the  expense  of  technical  design  efficiency,  if 
necessary);  and  (3)  design  software  which  is  strongly  influenced  by 
factors  which  will  reduce  LCC  -  particularly  those  standards  relating  to 
design,  languages,  inter-system  and  intra-system  interfaces. 

These  guidelines  emphasize  that  software  should  be  designed  to  make 
changes  easy  -  and  that  it  is  worth  extra  time,  effort,  and  resource 
expenditures  during  the  development  phase  to  make  the  software  reliable, 
maintainable,  and  less  costly  over  its  operational  life  span.  These 
guidelines,  if  followed,  can  help  to  avoid  major  problems  in  system 
operation  in  the  Fleet.  If  software  is  allowed  to  become  complicated 
and  overly  refined,  a  simple  change  in  one  or  two  parameters  can  demand 
that  major  software  segments  be  replaced.  Careful  design  (including 
memory  medium)  with  regard  for  probable  programming  change  requirements 
can  simplify  the  software  change  problem  throughout  the  system's  service 
life.  Costs  of  updating  and  maintaining  software  during  the  system's 
service  life  can  be  controlled  only  if  the  PM  forces  the  design  in  a 
reliable,  maintainable  direction. 

The  PM  needs  software  expertise  available  in  his  program  from  the 
outset.  This  needed  expertise  is  frequently  in  short  supply.  Early 
designation  and  establishment  of  a  software  support  activity,  to  which 
weapon  system  software  support  for  the  operational  system  will  be  tran- 
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sitioned,  is  an  effective  way  to  acquire  expert  software  development 
advice  early  in  a  program.  Further,  this  early  designation  provides 
technical  assistance  in  monitoring  the  development  progress,  and  in 
analysis  and  solution  of  software  development  problems  as  they  occur. 
Finally,  this  procedure  should  also  ensure  a  smooth  transition  of  soft¬ 
ware  support  responsibility  at  the  proper  time.  Activity  personnel  will 
be  thoroughly  familiar  with  the  system  software  by  virtue  of  participa¬ 
tion  during  its  development.  Assistance  and  initial  guidance  in  inter¬ 
preting  and  applying  official  guidelines  for  software  management  are 
available  from  the  offices  listed  below. 

NAVMAT:  Tactical  Embedded  Computer  Program  Office  (TECPO), 

MAT-08Y 

NAVSEA:  Tactical  Embedded  Computer  Resources  Program  Office, 

PMS-408 

NAVAIR:  Computer  Resources  and  Avionics  Systems  Division, 

AIR-543 

NAVELEX:  ELEX  814 

There  are  no  golden  rules  which,  if  followed,  will  avoid  software 
problems  in  the  development  of  a  software  intensive  system.  Treating 
software  development  as  an  effort  equally  important  to  and  concurrent 
with  hardware  development  has  produced  Cue  best  results.  Paying  too 
little  attention  to,  or  neglect  of  software  has  produced  system  fail¬ 
ures.  As  in  all  aspects  of  program  management,  in  software  development 
as  in  total  system  development,  there  is  no  substitute  for  understanding 
what  must  be  done  and  doing  it  at  the  proper  time  in  the  acquisition 
process. 


DESIGN  FOR  THE  ENVIRONMENT 

Naval  systems  and  subsystems  must  be  designed  to  survive  and  func¬ 
tion  in  the  operating  or  combat  environment.  Specifications  governing 
the  design  must  reflect  this  need.  The  specifications  must  also  provide 
for  system  survivability  in  the  punishing  transportation  and  storage 
environments  that  are  likely  to  be  encountered  during  the  system's  life. 
The  formulation  of  these  specifications  cannot  be  undertaken  until  the 
environmental  compatibility  requirements  for  the  systems  and  subsystems 
have  been  developed  in  quantitative  form. 

The  environmental  conditions  likely  to  be  encountered  by  a  new 
system  may  be  considerably  different  from  those  encountered  by  the 
system  it  replaces.  The  altitude,  speed,  and  acceleration  forces  for 
aircraft  systems  and  associated  weapons  have  changed  with  each  new 
generation  of  aircraft.  Similarly,  a  subsystem's  location  on  an  air¬ 
craft  or  snip  will  greatly  influence  its  environment,  as  will  new  mate¬ 
rials  use  for  construction,  the  increased  density  and  diversity  of 
electromagnetic  fluxes,  renewed  emphasis  on  arctic  warfare,  and  many 
other  factors. 

Unfortunately,  environmental  specifications  for  ships  and  aircraft 
systems  have  traditional ly  been  covered  by  general  specifications. 
These  are  often  out  of  date  and  lack  the  detailed  information  required 
by  the  system  designers,  logisticians,  T&E  planners,  and  other  involved 


4-72 


in  the  system  acquisition  process.  Outmoded  or  insufficiently  detailed 
specifications  have  resulted  in  both  over-  and  under-testing  of  systems 
and  have  lead  to  some  substantial  delays  of  IOC. 

PMs  are  encouraged  to  have  specific  environmental  compatibility 
requirements  for  their  systems  and  equipment  developed  early  in  the 
acquisition  process.  These  requirements  should  be  based  upon  anticipat¬ 
ed  use  scenarios  in  much  the  same  way  as  is  done  for  expendable  ordnance 
items  (a  methodology  described  in  MIL-STD-1 670) .  It  is  also  recommended 
that  the  PM  require  those  who  submit  concepts  for  evaluation  in  the 
Concept  Exploration  Phase  to  identify  and  include  a  description  of 
environmental  conditions  unique  to  their  systems  proposed  mode  of  opera¬ 
tion,  or  logistic  support. 

Generally  speaking,  designers  of  ship  and  aircraft  systems  and 
their  included  non-expendable  subsystems  are  concerned  with  achieving 
compatibility  only  with  the  combat  environment.  Designers  of  expendable 
ordnance  items  and  many  Marine  Corps  items,  however,  are  concerned  not 
only  with  the  combat  environment,  but  with  the  whole  factory-to-target 
sequence  of  environments  as  well.  These  items  must  receive  special 
attention  in  the  determination  of  environmental  compatibility  require¬ 
ments  that  will  apply  to  their  development,  T&E,  production,  delivery, 
maintenance  repair,  and  employment  by  the  using  Coirenands.  For  these 
missiles,  torpedoes,  remotely  piloted  vehicles  (RPVs),  and  other  such 
items,  the  planning  and  detailing  of  a  Life  Profile  (LP),  variously 
called  a  Factory-to-Target  Sequence  (FTTS)  or  Service-Use-Profile  (SUP), 
and  the  preparation  of  a  Missile  Profile  (MP)  and  Environmental  Design 
Criteria  Documents  (EDCD)  are  early,  essential  activities  in  the  plan¬ 
ning  process.  These  documents  and  reports  require  a  time-phased  des¬ 
cription  of  the  events  and  environments  that  an  item  will  experience 
from  manufacture  to  final  expenditure  or  removal  from  the  operational 
inventory  including  the  item's  logistic  profile  and  one  or  more  mission 
profiles. 

Missiles  and  torpedoes  are  unique  among  the  types  of  ordnance 
equipment  employed  in  training  and  combat  operations.  Their  uniqueness 
derives,  in  part,  from  the  fact  that  although  they  are  categorized  as 
expendable,  they  are  still  subject  to  overhaul  and  maintenance  proce¬ 
dures.  They  can  and  often  do  spend  long  periods  of  time  in  both  live 
ano  dead  storage.  They  contain  explosive  material  and  hazardous  fuels 
as  well.  Inadvertent  detonation  or  ignition,  or  failure  to  function 
properly  after  intentional  detonation  or  ignition  commands,  may  have 
catastrophic  consequences.  Thus  it  is  necessary  that  these  weapons  be 
designed  to  withstand  the  many  extremes  of  temperature,  shock,  vibra¬ 
tion,  humidity,  etc.,  to  which  they  will  be  subjected  from  the  time  they 
are  accepted  at  the  place  of  manufacture  to  the  time  they  actually  reach 
the  target  (see  Figure  4-17).  To  so  design  these  weapons,  the  Life 
Profile  must  be  worked  out  and  the  extremes  of  the  several  environments 
that  will  be  experienced  by  the  weapons  must  be  determined. 

During  the  Concept  Exploration  Phase  the  PM  will  require  a  MP. 
This  report  is  extracted  from  the  LP  and  quantitatively  describes  the 
various  environments  that  a  given  weapon  may  encounter.  Each  environ¬ 
ment  is  categorized  as  damaging  or  non-damaging  and  the  rationale  for 
such  categorization  is  given.  A  MP  for  an  all-up  air-launched  missile. 
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for  example,  would  take  into  consideration  such  factors  as: 

1.  Proposed  logistics  cycle 

2.  Means  of  transportation  (truck,  railroad,  dolly,  etc.)  of  the 
weapon  from  one  location  to  the  next 


FIGURE  4-17.  System  Life  Cycle  Profile. 


3.  Range  of  time  spent  at  each  location  and  the  environment 
encountered  there 

4.  Identity  of  carrying  vehicle  (ship  or  aircraft)  on  which  the 
weapon  will  be  stored  or  carried,  or  from  which  it  will  be 
launched 

5.  Anticipated  locations,  in  or  on  the  carrying  or  launching 
vehicle,  where  the  weapon  will  be  carried  or  launched  from, 
and  the  mix  of  stores  carried  by  that  vehicle 

6.  Anticipated  combat  tactics  employed  by  the  carrying  or  launch¬ 
ing  vehicle  and  its  maneuvering  characteristics  and  limita¬ 
tions  (speed,  altitude,  depth,  etc.) 

7.  Anticipated  mission  profile  of  carrying  or  launching  vehicle 

8.  Anticipated  operational  deployment  areas  of  the  carrying  or 
launching  vehicle  vsea,  land,  arctic,  worldwide,  etc.) 

9.  Required  life  span  of  the  candidate  weapon  component  (storage 
life,  service  life,  number  of  flights,  etc.) 

10.  Operational  experience  of  existing  similar  weapons 
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From  this  information  the  design  team  can  develop  the  EDCD.  The 
EDCD  contains  specific  quantitative  design  parameters,  environmental 
design  requirements,  and  an  environmental  test  plan.  Since  the  EDCD  are 
an  integral  part  of  the  development  specification  that  defines  the 
allocated  baseline  configuration  for  the  FSD  Phase,  LP/MP/EDCD  activi¬ 
ties  should  commence  early  enough  in  the  Concept  Exploration  Phase  that 
the  EDCD  can  be  completed  and  approved  by  the  PM  well  before  the  conclu¬ 
sion  of  the  D&V  Phase. 

NWC  at  China  Lake,  California,  has  developed  an  information  data 
base  and  a  capability  that  permits  them  or  others  to  develop  LPs,  MPs 
and  EDCDs  for  weapon  and  other  ordnance  material. 


SURVIVABILITY 

Survivability  is  the  capability  of  a  system  to  continue  to  carry 
out  its  designated  missions  in  a  hostile  environment.  Survivability  is 
a  function  of  both  susceptibility  (the  combination  of  factors  that 
determine  the  probability  of  hit  by  a  given  threat)  and  vulnerability 
(the  extent  of  system  degradation  after  having  been  subjected  to  combat 
threats).  A  balanced  survivability  program  includes  the  analysis  of 
survivability  with  respect  to  all  anticipated  threats,  trade-off  stu¬ 
dies,  cost/benefit  analyses  to  determine  the  best  mixture  of  survivabi¬ 
lity  enhancement  techniques,  and  a  T&E  program  to  measure  and  evaluate 
performance.  In  evaluating  proposed  design  features  that  bear  on  survi¬ 
vability,  the  PM  and  his  staff  should  realize  that  high  survivability 
is,  in  effect,  a  force  multiplier. 

Congress  and  the  public  have  increasingly  taken  the  DOD  to  task  for 
developing  sophisticated  and  expensive  systems  that  do  not  have  reduced 
susceptibility  and  are  vulnerable  to  "cheap  kills"  or  to  particular 
threats.  DODI  5000.2  requires  that  survivability  be  considered  in 
acquisition  planning  under  both  mission  analysis  and  design  considera¬ 
tions.  The  Justification  for  Major  System  New  Start/Operational  Re¬ 
quirement/Required  Operational  Capability  ( JMSNS/0R/R0C)  must  include  an 
explicit  threat  statement.  Survivability  goals  and  thresholds  must  be 
given  in  the  milestone  review  documentation  (MRD).  System  vulnerability 
to  detection,  interference,  and  attack,  and  the  program  actions  chosen 
to  minimize  these  vulnerabilities,  must  be  discussed.  Both  nuclear  and 
non-nuclear  survivability  and  endurance  information  are  required.  DODD 
5000.3  requires  that  survivability/vulnerability  problems  and  their 
solutions  be  identified  in  DT&E  and  that  survivability/vulnerability  be 
evaluated  as  part  of  operation  effectiveness  in  0T&E.  NAVMATINST  3900.16 
requires  that  survivability  requirements  be  included  during  the  earliest 
conceptual  formulations  of  mission  essential  weapon  systems  (MEWS),  and 
that  the  requirements  be  addressed  as  a  major  issue  in  the  MRD  beginning 
with  Milestone  I.  Thus,  survivability  against  the  full  spectrum  of 
warfare  threats  must  be  treated  as  a  design  parameter  for  all  mission- 
essential  systems.  This  treatment  must  take  into  consideration  the 
protection  of  personnel.  Each  system  must  be  periodically  re-evaluated 
during  its  operational  life  cycle  to  determine  whether  survivability 
modifications  are  warranted. 


Figure  4-18,  adapted  from  MIL-STD-2072,  indicates  some  of  the  life- 
cycle  survivability  requirements.  MIL-STD-2072,  although  written  for 
aircraft  systems,  contains  advice  applicable  to  ship  and  submarine 
systems  as  wel 1  - 


l 
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Mission  and  Threat  Requirements 


The  criteria  for  combat  mission  effectiveness  and  the  description 
of  typical  combat  scenarios  will  be  provided  by  OPNAV.  A  description  of 
the  specific  threats  to  be  considered  will  be  provided  by  the  Naval  In¬ 
telligence  Command  via  OPNAV  and  should  include  the  full  threat-spectrum 
likely  to  be  encountered  including  electronic,  and  chemical,  biological, 
and  radiation  (nuclear)  (C8R)  threats.  Due  to  the  dynamic  nature  of  the 
evolving  threat,  the  PM  should  consider  a  Preplanned  Product  Improvement 
Program  ( P 3 1 )  to  enhance  survivability  against  new  threats. 


Weapons  Effects 


The  system  designers  must  consider  the  effects  of  all  weapons 
likely  to  be  encountered  during  combat.  These  effects  include  blast 
overpressure,  ionizing  and  thermal  radiation,  underwater  shock,  electro¬ 
magnetic  pulse  (EMP)  and  fallout  from  nuclear  weapons,  high-velocity 
fragments,  shaped  charge  and  blast  effects  from  conventional  weapons, 
electromagnetic  interference  of  both  a  "spoofing"  and  destructive  na¬ 
ture,  high-energy  lasers,  particle  beam  weapons,  and  chemical  and  biolo¬ 
gical  agents. 


RF  Susceptibility 

The  effects  of  RF  susceptibility  vary  from  complete  destruction  of 
a  system  to  diminished  performance  of  a  system  due  to  friendly  electro¬ 
magnetic  interference  (EMI)  or  enemy  electronic  countermeasures  (ECM). 
RF  susceptibility  is  increasing  in  severity  due  to  the  increased  reli¬ 
ance  on  electronics,  the  use  of  miniaturization  and  microminiaturization 
of  electronic  components,  and  the  exposure  of  system  to  higher  RF  flux 
densities. 

EMI  can  be  broken  down  into  two  classes:  sensitivity  degradation 
and  signal  distortion.  The  first  interfers  with  the  basic  detection 
processes  of  the  system  and  is  usually  associated  with  noise  or  noise¬ 
like  interference.  The  second  type  introduces  errors  or  accuracy  degra¬ 
dation  in  one  ;r  another  of  the  system  outputs.  The  second  is  more 
insidious  and  less  easily  detected.  Both  forms  may  result  in  catastro¬ 
phic  effects,  e.g.,  the  initiation  of  an  ordnance  firing  train  on  a 
carrier  deck,  the  obscuration  of  a  threat's  approach,  or  the  alteration 
of  a  compass  heading. 

RF  susceptibility  must  be  countered  by  proper  system  design  to 
prevent  entry  of  spurious  signals.  This  requires  an  acute  awareness  of 
the  problem  by  the  product  engineer  or  designer.  Reducing  RF  suscepti¬ 
bility  required  significant  effort  throughout  the  period  of  design 
evolution,  including  the  deliberate  T&E  of  the  system  for  such  suscepti¬ 
bility. 


4-76 


Vi 


U 


► 


M 


4-77 


FIGURE  4-18.  Life-Cycle  Survivability  Requirements. 


Electronic  Counter-Countermeasu res  (tCCM) 


DODD  C-4600.3,  Electronic  Counter  -  Countermeasures  (ECCM)  Policy 
states  that  "the  sponsoring  agency,  in  collaboration  with  the  user  and 
developer,  will  document  and  support  a  recommendation  for  an  appropriate 
level  of  ECCM  protection"  for  all  electronic  systems.  "The  minimum 
goals  for  ECCM  protection  will  be  to  provide  capabilities  comparable  to 
the  protection  afforded  the  complete  weapon  system...  (and)  the  develo¬ 
per  will  initiate  the  appropriate  action  to  ensure  that  adequate  threats 
signal  simulators  are  available  to  support  test  and  evaluation..." 


Countermeasures 

System  designers  must  consider  both  active  and  passive  methods  for 
interfering  with  an  enemy's  intelligence  gathering,  platform,  and  weapon 
sensors  and  thus  reduce  his  ability  to  deliver  weapons  to  the  system. 
Countermeasures  will  include  such  diverse  techniques  as  camouflage, 
obscuration  devices  (smokes  and  aerosols),  chaff,  decoys,  jammers,  and 
electronic  support  measures  for  the  detection  of  threats. 

System  Signal  reduction.  One  of  the  most  effective  means  of  in¬ 
creasing  a  system's  survivability  is  by  reducing  its  susceptibility  to 
detection  and  targeting.  Signature  reduction  -  the  reduction  of  radar 
cross  section,  infrared  radiation,  acoustic  and  visual  signatures,  as 
well  as  other  emissions  both  intended  and  unintended  -  reduces  the 
enemy's  ability  to  determine  the  presence  or  location  of  a  system  or  to 
guide  his  weapons  to  it,  and  increases  the  effectiveness  of  countermea¬ 
sures. 


Vulnerability  Reduction 


Many  techniques  and  disciplines  can  be  used  to  enhance  survivabili¬ 
ty  of  mission-essential  systems  and  subsystems,  and  may  apply  to  plat¬ 
form  design,  to  system-subsystem-component  design,  to  personnel,  or  to 
any  combination  of  these,  depending  on  the  threat.  Certain  techniques 
are  basic  to  survivability,  such  as  choice  of  materials  and  components; 
their  location,  shielding,  component  arrangements,  redundancy,  and  re¬ 
configuration  after  damage.  Different  threats  require  different  design 
approaches.  Biological  and  chemical  threats  require  design  of  ship¬ 
board-collective  protection,  decontamination,  and  washdown  systems,  plus 
clothing  and  prophylaxis  for  shipboard  personnel.  Protective  clothing 
and  equipment  are  required  for  aircrews.  Nuclear  weapon’s  effects  will 
require  shock  hardening  of  sea  systems  to  underwater  shock,  electromag¬ 
netic  pulse  protection  of  platforms  and  systems,  design  of  electronic 
equipment  to  protect  it  from  ionizing  radiation,  and  design  of  ship 
superstructure  and  exposed  equipment  to  provide  protection  from  blast 
overpressure  and  thermal  radiation. 

The  threats  of  conventional  weapons  are  blast,  fragments,  shaped 
charges,  and  missiles  and  their  debris.  In  addition  to  basic  surviva¬ 
bility  techniques,  equipments,  ordnance,  and  systems  should  be  designed 
•for  damage  tolerance.  Harden  features,  such  as  armor,  may  be  appropri¬ 
ate.  In  some  cases  tne  backfit  of  hardening  features  may  be  required 
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when  no  other  solution  is  possible.  The  costs  of  design  against  each 
threat  are  not  necessarily  additive,  because  design  features  provide 
protection  against  more  than  one  threat.  Skillful  design  and  integra¬ 
tion  of  subsystems  into  the  platform  will  provide  maximum  survivability 
at  minimum  cost. 

Warfare  engagements  are  expected  to  be  of  increasingly  shorter 
duration  and  involve  the  exchange  of  sophisticated  and  devastating 
weapons.  Aircraft  are  being  designed  for  sustainability  (operating  of 
systems  at  a  reduced  level  of  capability  rather  than  catastrophic  fai¬ 
lure  after  damage);  ability  to  return  to  the  carrier  or  base  after 
damage;  and  rapid  battle  damage  repairability.  Ships  are  designed  for 
reconfiguration  of  propulsion  and  generation  of  electrical  power  after 
damage.  Procedures  have  been  developed  for  assessing  the  status  of 
combat  systems  after  damage  and  reconfiguration  of  systems  for  maximum 
combat  capability. 


Personnel  Protection 

The  protection  of  personnel  against  primary  and  secondary  weapons 
effects  is  an  extremely  important  aspect  of  survivability.  This  protec¬ 
tion  includes  the  selective  use  of  armor,  CBR  filter,  protective  cloth¬ 
ing,  and  decontamination  equipment. 


Survivability  Program  Assistance 

Assistance  in  setting  up  a  survivability  program  may  be  obtained 
from  NAVMAT-08D,  NAVAIR-5184  (the  Navy  Air  Combat  Survivability  Office), 
NAVELEX-51024,  and  NAVSEA-322  (Ship  Survivability  Division).  Technical 
assistance  is  available  from  NADC  and  NWC  for  aircraft,  aircrews  and 
aircraft  systems;  NSWC  and  DTNSRDC  for  ship  structure  and  hull,  mechani¬ 
cal  and  electrical  (HME)  systems;  DTNSRDC  for  submarines;  NOSC  for 
command,  control,  and  communication  systems;  NSWC  for  nuclear  weapons 
effects;  NSWC  and  NWC  for  combat  systems;  NRL  for  fire  fighting;  NSWC 
for  biological  and  chemical  defense;  NSWC  and  DTNSRDC  for  ship  radar 
cross  section  and  infrared  signature  reduction;  NADC  for  aircraft  radar 
cross  section  reduction;  and  NWC  for  aircraft  infrared  signature  reduc¬ 
tion. 


NAVY  STANDARDIZATION 

The  PM  should  make  maximum  use  of  existing  Navy  standard  hardware 
and  software.  Use  of  standard  materials  and  procedures  lead  to  LCC 
benefits,  higher  reliability,  and  established  logistic  support  base, 
simplified  training,  and  proper  documentation.  System  contractors  will 
often  try  to  convince  the  PM  that  their  particular  product  has  technical 
advantages  over  the  standard  hardware  because  it  has  been  optimized  for 
the  particular  system  that  is  being  acquired.  It  the  new  product  is 
utilized,  however,  the  program  must  contend  with  an  unknown  entity  and 
its  attendant  negative  impact  on  the  ILS  for  the  entire  system. 
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Examples  of  Navy  standardization  policy  are  the  requirements  gov¬ 
erning  the  use  of  tactical  embedded  computers  and  standard  equipment 
modules  (SEM).  Utilization  of  a  non-standard  tactical  computer,  or 
electronic  modules  in  other  than  SEM  format,  requires  prior  approval  of 
CNM  (MAT-08).  The  Navy  standard  computer  include  the  UYK-7,  UYK-20, 
AYK-14  and  UYS-1 .  Under  development  are  the  UYK-44,  a  replacement  for 
the  UYK-20;  UYK-43,  a  replacement  for  the  UYK-7,  and  the  enhanced  modu¬ 
lar  signal  processor  (EMSP),  a  replacement  for  the  UYS-1.  There  are 
other  standard  computer  peripherals  such  as  disk  files,  displays,  magne¬ 
tic  tape  units,  as  well  as  support  software  and  tools.  The  PM  should 
coordinate  with  Headquarters,  NAVMAT  (MAT-08Y)  to  obtain  additional 
information  on  CNM  policy  in  this  area. 

The  optimum  level  of  standardization  for  a  program  can  be  achieved 
with  the  assistance  of  the  Defense  Logistics  Agency  (DLA)  through  their 
Military  Parts  Control  Advisory  Groups  located  at  the  Defense  Electro¬ 
nics  Supply  Center  in  Dayton,  Ohio,  the  Defense  Industrial  Supply  Center 
in  Philadelphia,  Pennsylvania,  the  Defense  General  Supply  Center  in 
Richmond,  Virginia,  and  the  Defense  Construction  Supply  Center  in  Colum¬ 
bus,  Ohio.  DLA  engineers  provide  the  Navy  with  advice  and  recommenda¬ 
tions  on  the  selection  and  use  of  DOD-preferred  and  standard  parts 
during  the  design  phase  of  the  acquisition  process.  Non-standard  parts 
submitted  for  evaluation  are  considered  for  suitability  for  government 
re-procurement  and  as  potential  candidates  for  standardization.  In  con¬ 
junction  with  the  parts  advisory  service,  DLA  engineers  may  prepare  or 
cause  to  be  prepared,  military  specifications  or  standards  needed  to 
procure  and  standardize  new  parts.  Final  authority  for  the  selection 
and  use  of  parts  during  design  rests  with  the  Navy.  The  PM  will  find 
the  DLA  a  useful  resource  for  helping  contractors  determine  commonality 
of  parts,  assisting  in  selecting  he  latest  preferred  standard  parts, 
interpreting  specification  requirements  and  determining  applicability, 
modifying  or  recommending  modification  to  existing  military/industry 
specifications  to  meet  the  latest  requirements,  and  clarifying  parts 
control  procedures  and  problems. 


SAFETY 

Safety  is  defined  as  that  attribute  of  a  system  or  operation  that 
renders  it  free  from  conditions  that  can  cause  death,  injury,  occupa¬ 
tional  illness,  or  damage  to  or  loss  of  equipment  or  property  (adapted 
from  paragraph  3.5  of  MIL-STD  882A).  If  follows  that  for  any  program, 
the  PM  must  concern  himself  with  two  aspects  of  system  safety:  (1)  the 
safety  of  personnel,  material,  and  facilities  involved  in  the  develop¬ 
ment,  test,  production,  deliver,  and  installation  of  the  system  and  (2) 
the  safety  of  personnel,  material,  and  facilities  involved  in  and  af¬ 
fected  by  the  operation,  storage,  and  maintenance  of  the  system  itself 
or  its  subsystems  and  components.  Since  safety  is  achieved  in  part 
through  good  design,  the  contractor  must  focus  on  safety  at  the  earliest 
stages  of  concept  development. 

No  system  can  be  rendered  completely  free  of  hazard  or  made  totally 
safe.  MIL-STD  882A  defines  system  surety  as  "the  optimum  degree  of 
safety  within  trie  constraints  of  operational  effectiveness,  time,  and 
cost,  attained  through  specific  application  of  system  safety  management 
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and  engineering  principles  whereby  hazard  are  identified  and  risk  mini¬ 
mized  throughout  all  phases  of  the  system  life  cycle".  System  safety 
programs  must  be  conceived/operated  with  the  end  in  view  of  first  iden¬ 
tifying  hazards;  then  minimizing  the  risk  associated  with  those  hazards. 

System  safety  engineering  is  a  philosophy  of  resource  management  in 
which  the  identification  and  elimination  or  control  of  hazards  is  sought 
in  an  effort  to  reduce  losses  of  men  and  equipment.  DODI  5000.36, 
implemented  by  NAVMATINST  5100.6,  requires  organized  use  of  system 
safety  engineering  and  system  safety  management  for  each  major  D0D 
system  acquisition. 

By  early  consideration  of  system  safety  engineering,  potential 
hazards  can  be  identified  and  minimized  through  design  changes  at  mini¬ 
mal  cost.  If  hazards  are  not  discovered  until  after  the  design  is 
completed,  minimization  of  the  associated  risk  is  often  prohibitively 
costly  in  terms  of  time  and  dollars.  If  system  safety  is  omitted  from 
consideration  as  a  design  attribute,  the  PM  will  encounter  difficulty  in 
obtaining  a  safety  sign-off  for  procurement,  a  determination  of  opera¬ 
tional  suitability,  or  approval  for  full  production  (AFP). 

The  Weapons  System  Explosive  Safety  Review  Board  (WSESRB)  was 
established  by  the  CNM  (NAVMATINST  8020.1)  as  a  part  of  the  naval 
explosives  safety  program.  The  Board's  scope  of  cognizance  includes  the 
review  of  all  ammunition,  explosive  devices,  weapons,  weapon  systems 
(including  pyrotechnics  and  chemical  or  biological  agents),  handling 
hardware,  stowage  factors,  processing,  test,  and  checkout  equipment,  to 
determine  the  nature  and  extent  of  the  mechanical,  thermal,  chemical, 
electrical  and  electromagnetic  radiation  hazards  that  the  systems  and 
subsystems  present  to  men  and  material.  The  WSESRB  has  responsibility 
for  the  review  of  designs,  analysis,  test  results,  operational  and 
logistic  plans,  and  all  explosive  safety  documentation,  procedures, 
precautions,  instructions,  and  training  related  to  weapon  systems,  sub¬ 
systems,  and/or  explosive  ordnance  component  development. 

For  systems  using  explosive,  pyrotechnics,  or  other  hazardous  mate¬ 
rials,  WSESRB  reviews  are  mandatory  prior  to  advancing  to  each  phase  of 
development,  technical  evaluation,  operational  evaluation,  and  AFP. 
After  completion  of  the  review,  the  Board  will  either  recommend  advance¬ 
ment  to  the  next  phase  of  the  acquisition  cycle  or  will  make  appropriate 
recommendations,  from  an  explosives  safety  viewpoint,  on  the  desirabili¬ 
ty  of  further  development  or  change  before  advancing  to  either  the  next 
state  of  development  or  introduction  to  the  Fleet.  Corrective  action 
must  be  taken  before  final  Board  approval. 

System  safety  engineering  support  exists  at  all  levels  of  the  Navy 
organization.  The  various  Commands  usually  have  identified  a  principal 
for  safety  who  is  familiar  with  the  various  system  safety  requirements 
at  that  particular  level  of  the  organization.  The  principal  for  safety 
can  direct  the  PM  to  ensure  pjoper  safely  involvements.  NAVMAT-04F, 
NAVAIR-09E,  and  NAVSEA-04H  are  examples  of  safety  support  codes. 


PRODUC I B I L I TY 


The  Navy  is  placing  renewed  emphasis  on  reducing  acquisition  costs. 
Producibility  is  the  discipline  of  reducing  production  costs  while 
maintaining  quality.  There  are  several  factors  that  contribute  to  the 
current  concern  with  producibility.  First,  the  technology  in  manufac¬ 
turing  processes  and  materials  is  growing  rapidly  and  it  requires  con¬ 
centrated  effort  to  stay  abreast  of  the  state-of-the-art  in  materials, 
manufacturing  processes,  and  control.  Second,  technical  data  packages 
(TDPs)  have  in  the  past  been  almost  void  of  meaningful  reviews  that 
address  producibility.  Such  reviews  would  include  inspectability,  which 
is  one  of  the  key  elements  of  a  producibility  review.  Third,  produc¬ 
tion-support  engineers  are  kept  extremely  busy  putting  out  brush  fires 
that  should  have  been  resolved  in  the  early  design  stages. 

DODD  5000.34,  Defense  Production  Management,  states  that  "each  DOD 
component  having  authority  and  responsibility  for  acquisition  of  major 
systems  shall  establish  a  focal  point  responsible  for  policy  and  proce¬ 
dures  to  implement  the  provision  of  this  directive  and  shall  coordinate 
production  management  activities".  The  Navy  is  charged  with  the  respon¬ 
sibility  for  "assuring  that  consideration  is  given  to  the  producibility 
of  proposed  concepts  during  the  D&V  Phase". 

Producibility  is  defined  as  the  inherent  design  attribute  that 
enables  a  configuration  item  to  meet  all  of  its  performance  objectives 
within  the  design  constraints,  and  yet  to  be  produced  in  the  shortest 
total  time,  at  the  lowest  cost,  with  the  most  readily  available  mate¬ 
rials,  using  the  most  advantages  processes  and  assembly  methods.  Note 
that  the  performance  objective  (including  R&M)  must  not  be  compromised 
or  adversely  affected  by  factors  introduced  to  maximize  producibility. 
The  design  which  meets  the  performance  objectives,  and  yet  can  be  pro¬ 
duced  in  the  simplest  and  most  economical  manner,  will  have  the  maximum 
practical  producibility.  Product  and  production  engineers  must  follow 
cost-effective  design  practices  during  all  phases  of  the  acquisition 
process.  From  the  outset  of  the  program  they  must  seek: 

1 .  To  maximize: 

a.  Simplicity  of  the  design 

b.  Standardization  of  materials  and  components 

c.  Potential  industrial  production  capability 

d.  Repeatability  of  processes  employed 

e.  Inspectability  of  the  product 

f.  Provisions  for  industrial  safety  in  production 

2.  To  minimize: 

a.  Use  of  critical  (strategic)  materials 

b.  Need  for  special  production  tooling  and  special  test  systems 

c.  Use  of  critical  processes 

d.  Need  for  high  skill  levels  by  production  personnel 

e.  Introduction  of  design  changes  in  production 

f.  Use  of  limited  availability  items  and  processes 

g.  Use  of  proprietary  items 
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Production  engineers  must  be  brought,  into  the  picture  as  soon  as 
the  first  drawings  are  presented  if  the  producibility  attribute  is  to  be 
achieved  to  an  acceptable  degree.  A  strategy  for  achieving  a  high 
degree  of  producibility  should  be  an  integral  part  of  the  documented 
acquisition  strategy. 

In  summary,  producibility  is  an  inherent  in  the  design.  Most  of 
the  producibility  attribute  and  hence  most  of  the  production  costs  are 
locked  in  during  the  Concept  Exploration  and  D&V  Phases.  To  achieve  an 
acceptable  degree  of  producibility,  the  PM  must  employ  a  systematic 
approach  from  the  beginning  of  the  program.  To  do  so  will  pay  great 
dividends  through  the  reduction  of  costly  delays  during  the  FSD  and 
early  Production  Phases  and  reduction  of  the  need  for  expensive  modifi¬ 
cation  during  the  Production  and  Deployment  Phase. 


DOCUMENTATION 

The  product  of  a  development  program  is  a  documentation  package. 
Documentation  can  be  grouped  into  three  categories  as  follows: 

1.  Program  documentation  to  justify,  establish,  and  report  pro¬ 
gress  on  the  program  to  higher  management  echelons 

2.  Management  documentation  to  facilitate  management  of  the  pro¬ 
gram 

3.  Product  documentation  to  describe  the  product  and  enable  its 
development,  procurement,  inspection,  acceptance,  logistic 
support,  and  use. 

Documentation  requirements  should  be  limited  to  those  that  are 
essential  to  the  acquisition  process. 

The  requirements  for  documentation  items  in  the  first  category  is 
mandatory.  Their  format,  content,  detail,  and  timing  have  been  speci¬ 
fied  by  DOD,  SECNAV,  OPNAV,  CNM,  and  SYSCQM  directives.  The  PM  and  his 
staff  should  consult  the  basic  directive  for  a  discussion  of  the  style, 
format,  and  content  for  each. 

The  second  category  consists  of  the  documentation  required  by  the 
PM  from  contractors,  in-house  support  groups,  and  his  own  staff.  This 
helps  the  PM  to  provide  the  documentation  required  by  higher  authority 
and  to  justify  and  manage  the  program's  activities.  Some  of  the  docu¬ 
mentation  will  be  mandated  by  NAVMAT  or  the  parent  SYSCOM  and  some  by 
the  PM  himself. 

The  third  category  consists  of  the  documentation  necessary  to 
permit  manufacture  of  the  system  in  question  by  a  qualified  industrial 
concern,  inspection,  and  acceptance  into  the  inventory  by  government 
inspection  services,  operation,  and  maintenance  by  the  using  Commands. 
Examples  of  the  types  of  documentation  normally  found  in  this  third 
category  include  production  drawings  and  specifications,  operating  man¬ 
uals,  training  manuals,  maintenance  handbooks,  logistics  plans,  and 
parts  lists.  Various  aspects  of  product  documentation  are  discussed  in 


this  Guide  under  the  critical  topics  "Specifications",  "Conf iguration 
Management"  and  "Contracting". 

In  the  area  of  documentation  not  mandated  by  higher  authority,  the 
PM  should  rigorously  evaluate  each  item  being  requested  to  ensure  that 
it  is  essential,  does  not  put  an  unacceptable  burden  on  the  preparing 
group  or  individual  and,  most  important,  that  it  does  not  call  for 
information  that  is  available  in  another  form  elsewhere.  A  suggested 
method  for  evaluating  the  essentiality  of  such  documentation  is  to 
assign  each  item  an  arbitrary  essentiality  index.  Then  by  estimating 
the  cost  in  manpower  and  time  to  produce  the  item  ar.d  weighing  it 
against  the  essentiality  rating,  a  cost-effectiveness  rating  can  be 
arrived  at. 


SPECIFICATIONS 

The  system,  development,  and  product  specifications  are  among  the 
most  important  of  the  document  produced  during  the  acquisition  process. 
A  specification  is  defined  as  a  document,  intenaed  primarily  for  use  in 
procurement,  that  accurately  describes  the  essential  technical  require¬ 
ments  for  items,  materials,  or  services,  including  the  procedures  for 
determining  that  the  requirements  have  been  met  (DODD  4120.3). 

System  and  equipment  specifications,  when  invoked  by  a  contract, 
become  a  part  of  that  contract  and  as  such  are  legally  enforceable. 
When  disagreements  between  the  government  and  a  contractor  develop,  the 
issues  will  be  resolved  on  the  basis  of  what  the  specifications  say,  and 
not  what  they  are  intended  to  say.  The  PM  must  realize  that  the  prepa¬ 
ration,  review,  and  maintenance  of  the  program's  specification  require¬ 
ments  are  activities  worthy  of  the  most  competent  members  of  the  PMO  and 
need  the  undivided  attention  of  one  or  more  people  who  are  skilled  in 
specification  matter. 

At  the  first  writing,  specifications  seldom  achieve  the  clarity  of 
expression  required  to  make  them  unambiguous.  Moreover,  they  often 
contain  requirements  and  values  that  were  intuitively  arrived  at  and  are 
subsequently  shown  to  be  either  unnecessarily  restrictive  or  not  re¬ 
strictive  enough.  Specifications  are  living  documents  that  must  be 
reviewed,  maintained,  changed,  and  updated  to  eliminate  ambiguities, 
errors,  and  unnecessary  requirements,  and  to  reflect  the  current  reali¬ 
ties  of  total  program  requirements. 

As  system  complexity  grows  and  the  number  of  recognizable  subsys¬ 
tems  increases,  a  program  manager  will  find  it  helpful  to  have  his 
configuration  specialists  prepare  a  specification  tree.  The  tree  should 
contain  a  rank  and  order  listing  of  all  system,  subsystem,  equipment 
assembly,  and  component  specifications  that  will  be  required  to  support 
the  acquisition  process  and  the  spare  parts  procurement  program.  The 
tree  should  also  show,  for  each  specification  listed,  the  program  team 
action  engineer  (the  team  member  responsible  for  the  specifications 
preparation,  review  and  approval),  the  date  by  which  approval  is  requir¬ 
ed,  and  the  current  status.  Status  reviews  of  the  specification  tree 
should  be  scheduled  by  the  program  office  as  necessary. 
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The  specifications  established  during  the  acquisition  process  dif¬ 
fer  for  each  of  the  phases.  However,  they  should  all  state  only  the 
actual  minimum  needs  of  the  government  and  describe  the  supplies  and 
services  in  such  a  manner  as  to  encourage  competition  among  qualified 
suppliers.  They  should  avoid  restrictive  requirements  that  might  inhi¬ 
bit  the  submission  of  acceptable  proposals.  As  the  program  moves  for¬ 
ward,  the  specifications  will  become  progressively  more  detailed  (Figure 
4-19). 
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FIGURE  4-19,  Progressive  Definition  of  System  Specifications. 


Concept  Exploration  Phase 

The  specification  for  the  initial  solicitation  of  system  concepts 
is  little  more  than  a  copy  of  the  JMSNS/OR/ROC  itself.  Any  additional 
material  provided  in  the  solicitation  for  system  design  concepts  should 
assiduously  avoid  specification  in  terms  of  equipment,  but  rather, 
should  explain  the  need  in  mission  or  capability  terms,  schedule  objec¬ 
tives  and  constraints,  project  cost  objectives,  and  operational  con¬ 
straints. 
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D&V  Phase 


At  the  conrlusion  of  the  Concept  Exploration  Phase,  each  contractor 
that  has  been  selected  to  participate  in  the  D&V  Phase  should  have 
evolved  and  submitted  a  system  specification.  This  is  done  in  collabo¬ 
ration  with  the  PMO.  The  system  specification  is  defined  in  MIL-STD  480 
as  "a  document  which  states  the  technical  and  mission  requirements  for  a 
system  as  an  entity,  allocates  requirements  to  functional  areas  lor 
configuration  items)  and  defines  the  interfaces  among  the  functional 
areas".  The  D&V  Phase  system  specification  developed  during  the  Concept 
Exploration  Phase  should  have  avoided  all  details  that  could  later 
inhibit  the  construction  of  critical  subsystems,  equipment,  and  compo¬ 
nents,  or  the  demonstration  of  the  concept's  technological  feasibility. 
It  is  this  system  specification  that  establishes  the  functional  baseline 
configuration  for  a  proposed  system.  The  system  specification  will 
constrain  the  contractor's  efforts  and  will  be  refined  during  the  D&V 
Phase. 


FSD  Phase 

By  the  end  of  the  D&V  Phase,  the  contractors,  in  collaboration  with 
the  program  system  engineer, will  have  refined  their  system  specifica¬ 
tions.  The  specifications  will  update  the  system  performance  and  com¬ 
patibility  requirements  and  reflect  the  current  definition  of  the  system 
and  the  allocation  of  requirements  to  the  several  functional  areas  or 
configuration  items.  In  addition,  each  competing  contractor  should  have 
submitted  a  series  of  development  specifications.  Such  a  specification 
is  defined  in  MIL-STD  480  as  "a  document  applicable  to  an  item  below  the 
system  level  which  states  performance,  interface,  and  other  technical 
requirements  in  sufficient  detail  to  permit  its  design,  engineering  for 
service  use,  and  evaluation".  The  update  system  specification  and  the 
series  of  development  specifications  constitute  the  Allocated  Baseline 
Configuration  that  will  constrain  contractor  efforts  during  the  FSD 
Phase.  The  specifications  should  not  contain  a  degree  of  detail  that 
would  inhibit  the  important  trade-off  studies  and  design  evolution 
process  vital  to  this  phase. 


Production  and  Deployment  Phase 


By  the  time  the  fsd  Phase  has  been  concluded,  the  contractor ( s) ,  in 
close  collaboration  with  the  PMO,  should  have  provided  a  final  update  of 
the  system  specification  and  a  series  of  production  specifications.  A 
product  specification  is  defined  in  MIL-STD  480  as  "a  document  applic¬ 
able  to  a  production  item  below  the  system  level  which  states  item 
characteristics  in  a  manner  suitable  for  procurement,  production,  and 
acceptance".  The  production  specifications  should  provide  all  the  de¬ 
tail  necessary  to  permit  economical  procurement  of  functional  elements 
that,  when  assembled  into  a  system,  will  perform  as  a  system  in  accor¬ 
dance  with  the  current  system  specification.  These  production  specifi¬ 
cations  consist  of  two  distinct  types,  the  function  specification  (per¬ 
formance)  and  che  fabrication  specification  (design). 
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The  technical  data  package  that  represents  the  formally  accepted 
first  edition  (drawings  and  specifications)  required  to  produce,  test, 
and  accept  the  configuration  item  is  evolved  during  the  Production  and 
Deployment  Phase.  This  pacKage  constitutes  the  Product  Baseline  Con¬ 
figuration  (see  par.  '10.3,  MIL-STD  480)  of  the  system  and  will  be 
contractually  invoked  fo.  any  procurements  of  the  system,  or  its  parts, 
for  service  use. 


CONFIGURATION  MANAGEMENT 

Configuration  management  is  a  discipline  applying  administrative 
direction  and  surveillance  to  (1)  identify  and  document  the  functional 
and  physical  characteristics  of  a  configuration  item,  (2)  control  chan¬ 
ges  to  those  characteristics,  and  (3)  record  and  report  the  change, 
process,  and  implementation  status.  The  purpose  of  configuration  man¬ 
agement  is  to  prevent  engineering  anarchy  and  permit  orderly  develop¬ 
ment,  recording,  reproduction,  and  support  of  a  system.  Configuration 
management  is  accomplished  through  the  Functional,  Allocated,  and  Pro¬ 
duct  Baseline  Configurations.  Each  of  these  is  identified  by  a  document 
or  set  of  documents. 

The  FUNCTIONAL  BASELINE  CONFIGURATION  is  defined  in  the  initial, 
approved  system  specification.  It  establishes  the  requirements  for  the 
system  as  an  entity,  allocates  those  requirements  tc  functional  areas, 
and  defines  the  interfaces  between  and  among  the  functional  areas.  This 
baseline  is  invoked  at  the  initiation  of  the  D&V  Phase. 

The  ALLOCATED  BASELINE  CONFIGURATION  is  defined  in  a  set  of  devel¬ 
opment  specifications.  It  establishes  the  performance,  interface,  and 
other  technical  requirements  for  configuration  items  identified  in  the 
system  specification's  functional  areas.  The  development  specifications 
and  the  system  specification  constitute  the  baseline  at  the  initiation 
of  the  FSD  Phase. 

The  PRODUCT  BASELINE  CONFIGURATION  consists  of  a  set  of  product 
specifications  for  the  identified  config  .ration  items  in  the  system 
specification's  functional  areas.  The  product  specifications  will  con¬ 
sist  of  either  or  both  the  function  or  performance  specifications. 
These  establish  performance,  interface,  and  interchangeability  require¬ 
ments  and  characteristics  (form,  fit,  and  function).  Product  specifica¬ 
tions  also  include  fabrication  or  design  specifications  and  drawings 
that  establish  detailed  product  descriptions  (down  to  the  lowest  level 
of  interchangeability)  in  the  form  of  performance  requirements,  and  the 
test  and  inspection  required  to  assure  proper  fabrication,  adjustment, 
assembly,  and  acceptance.  These  drawings  and  specifications  and  the 
currently  approved  system  specification  constitute  the  baseline  for  the 
Production  and  Deployment  Phase.  Once  a  baseline  is  established  it  may 
not  be  changed  except  by  formal  change  action.  Procedures  for  these 
baseline  changes  are  covered  in  MIL-STD  480. 

At  no  point  is  a  system's  documentation  package  finally  and  perma¬ 
nently  fixed.  The  lessons  learned  from  full-scale  production  will  have 
an  impact  on  the  design  package,  as  will  feedback  from  the  Fleet  after 
the  system  is  developed.  A  configuration  control  program  is  necessary 


to  accommodate  changes  to  the  design  package. 

Configuration  management  is  intended  to  control  configuration  chan¬ 
ges,  not  to  prevent  them.  The  formalities  of  configuration  control 
should  not  inhibit  the  accomplishment  of  necessary  changes  of  force 
bypassing  of  the  change  control  procedures. 

During  the  design  evolution  in  the  Concept  Exploration,  D&V  and  FSD 
Phases,  rapid,  controlled  changes  are  necessary.  Change  control  proce¬ 
dures  for  these  phases  should  be  implemented  and  administered  at  the 
program  level.  Implementation  and  administration  should  shift  to  the 
Change  Control  Board  (CCB)  of  the  procuring  SYSCOM  once  the  product 
baseline  configuration  is  established  (usually  when  a  contract  is  enter¬ 
ed  into  that  includes  items  for  service  use).  Total  control  of  the 
emerging  product  baseline  configuration  should  be  taken  over  by  the 
government  not  later  than  the  start  of  formal  TECHEVAL,  Board  of  Inspec¬ 
tion  and  Survey  IBIS)  trials,  or  OPEVAL,  whichever  come  first.  Changes 
should  be  allowed  only  when  it  can  be  justified  by  cost-effectiveness  or 
for  the  correction  of  problems  or  failure. 

Effective  control  procedures  will  hopefully  eliminate  the  nice-but- 
not-necessary  changes  that  keep  designs  in  a  state  of  turmoil,  lead  to 
litigation,  and  unnecessarily  burden  the  logistic  support  system  and 
training  program.  Nevertheless,  configuration  control  should  not  become 
so  strict  and  burdensome  as  to  arrest  or  inhibit  the  design  maturation 
process.  Change  will  always  be  necessary  to  enhance  design  attributes 
such  as  reliability,  maintainability,  and  producibility;  to  correct 
latent  design  deficiencies  discovered  by  ongoing  follow-on  test  and 
evaluation  (FOT&E)  and  production  acceptance  test  and  evaluation  (PAT&E) 
programs;  to  embrace  applicable  new  technology,  and  to  accommodate 
changing  tactics  and  new  threats.  So  long  as  changes  are  carefully 
controlled  and  accounted  for  in  the  management  system,  they  can  signifi¬ 
cantly  enhance  the  utility  of  the  system. 


TEST  AND  EVALUATION  (T&E) 

Every  system  developed  or  used  by  the  Navy  must  be  tested  many 
times  during  its  life  cycle.  Tests  are  undertaken  to  demonstrate  feasi¬ 
bility,  address  areas  of  risk,  aid  in  the  determination  of  design  al¬ 
ternatives  and  trade-offs  necessary  to  best  achieve  project  objectives, 
and  to  determine  the  performance  of  items  under  controlled  conditions 
that  approximate  the  expected  operational  conditions. 

Evaluation  of  the  data  obtained  from  these  tests  forms  the  basis 
for  redesign  action  and  a  host  of  other  management  decisions  that  govern 
the  advance  of  a  program  through  the  acquisition  process.  The  relation¬ 
ship  of  the  overall  T&E  program  to  the  acquisition  process  is  shown  in 
Figure  4-20. 


Requirements 

Navy  system  acquisition  policy  emphasizes  that  demonstration  per¬ 
formance  is  the  pacing  requirement  of  acquisition  programs.  DODD  5000.3 
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establishes  policy  for  the  conduct  of  T&E  by  the  military  departments  in 
the  acquisition  of  defense  systems.  0PNAV1NST  3960. 1  OB  implements  DOOD 
5000.3  and  establishes  Navy  policy  for  T&E.  This  is  amplified  by  OPNAV- 
NOTE  3950  of  30  Mar  1983,  NAVMATINSTs  3960.6,  3960.7,  and  3960.8.  These 
documents  regulate  three  types  of  testing:  DT&E,  .  OT&E  and  production 
acceptance  test  and  evaluation  (PAT&E);  and  establish  selection  policy 
for  Land-Based  Test,  Sites. 

Development  Test  and  Evaluation  (OT&E).  DT&E  must  be  addressed 
early  m  the  program  to  bring  to  light  flaws  in  design,  performance,  or 
construction  techniques.  DT&E  is  a  tool  for  pinpointing  problem  areas 
in  their  early  stages.  Whenever  possible,  simulation  and  laboratory 
testing  should  be  conducted  prior  to  the  expensive  field  tests.  As  well 
as  being  cost  effective,  this  procedure  also  permits  more  effective  and 
efficient  field  tests.  Environmental  testing,  reliability  testing,  and 
testing  of  breadboard  parts  and  components  are  part  of  the  design  pro¬ 
cess.  These  tests  permit  the  designer  to  catch  deficiencies  at  a  cor¬ 
rectable  stage,  aid  in  the  selection  of  conceptual  and  design  alterna¬ 
tives,  and  determine  the  extent  to  which  technical  and  operational 
requirements  are  being  met  as  development  proceeds. 

In  the  early  acquisition  phases,  DT&E  is  conducted  by  design  acti¬ 
vities  and  the  participating  laboratories  and  centers.  As  the  design 
evolves,  SYSCOM-sponsored  test  activities  are  called  on  to  conduct  T&E 
prescribed  by  the  FM  and  the  parent  Command.  TECHEVAL  is  conducted  to 
enable  the  PM  and  his  team  to  independently  assess  the  status  of  the 
emerging  design  and  ultimately,  to  establish  a  basis  for  certification 
of  readiness  for  OPEVAL.  The  final  DT&E  effort  is  in  support  of  the 
modifications  undertaken  to  correct  design  deficiencies  revealed  by 
ongoing  OT&E  and  PAT&E  programs. 

Operational  Test  and  Evaluation  (OT&E).  The  OT&E  program  is  con¬ 
ducted  Ey  the  Operational  Test  and  Evaluation  Force  (OPTEVFOR),  an 
independent  Navy  test  activity  that  is  chartered  by  CNO.  In  the  concept 
formulation  period,  OPTEVFOR  may  lend  assistance  to  OPNAV  and  the  devel¬ 
oping  agencies  in  their  research  program  and  in  efforts  to  formulate 
statements  of  mission  need  and  to  conceptualize  approaches  to  meet  those 
needs.  In  the  initial  OT&E  program,  OPTEVFOR  assesses,  on  a  continuing 
basis,  the  prospects  for  operational  viability  of  system  concepts  pro¬ 
posed  for  meeting  an  operational  need  and  the  operational  suitability  of 
those  concepts  as  they  are  being  demonstrated,  validated,  and  developed 
for  service  use.  Finally,  in  the  formal  OPEVAL  portion  of  the  program, 
OPTEVFOR  assesses  the  degree  of  operational  effectiveness  and  operation¬ 
al  suitability  achieved  by  the  finished  design  and  develops  tactics  for 
the  system's  deployment.  In  OPEVAL,  OPTEVFOR  exercises  the  system  (or 
equipment)  in  conditions  that  simulate  as  closely  as  possible  the  ex¬ 
pected  operational  environment.  This  environment  includes  operation  and 
maintenance  by  Fleet-type  personnel,  test  scenarios  in  which  both  forces 
(friendly  and  enemy)  employ  realistic  tactics,  and  forces  that  fight 
back.  The  data,  findings,  and  recommendations  from  the  OT&E  program  are 
used  in  the  milestone  review  and  decision  process  and  form  the  basis  for 
CNO 1 s  AFP. 

In  the  follow-on  OT&E  (FOT&E)  program,  OPTEVFOR  may  be  required  to 
complete  testing  deferred  during  OPEVAL,  to  verify  correction  of  defici- 
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encies,  to  further  develop  tactical  data  and  tactics  for  the  system's 
employment,  and  to  conduct  any  additional  operational  test  that  CNO  may 
require. 

Concurrency  of  DT&E  and  OT&E.  The  PM,  after  consultation  with 
COMOPTEVFQR  and  with  the  approval  of  competent  authority,  may  combine 
portions  of  DT&E  and  OT&E.  This  is  most  frequently  done  in  the  develop¬ 
ment  of  large,  expensive  systems  or  systems  of  which  only  a  small  number 
will  be  produced  and  fielded.  Concurrency  is  encouraged  because  it  can 
save  significant  amounts  of  time,  test  items,  and  money.  Care  must  be 
taken  in  both  the  planning  and  conduct  of  these  combined  tests  to  ensure 
that  both  DT&E  and  OT&E  purposes  are  served.  Independent  evaluation  of 
the  tests  and  a  realistic  operational  environment  (including  operation 
and  maintenance  by  Fleet-type  personnel)  during  testing  are  mandatory 
for  OT&E. 

Production  Acceptance  T&E  (PAT&E).  The  PAT&E  program  consists  of 
the  aggregate  of  T&E  programs,  sponsored  and  undertaken  by  contractors 
and  the  government,  on  production-for-service-use  items.  These  programs 
are  conducted  both  prior  and  subsequent  to  the  items'  delivery  at  the 
point  of  manufacture.  PAT&E  is  intended  to  demonstrate  whether  or  not 
the  items  (systems,  subsystems,  equipment,  and  components)  comply  with 
the  requirements  and  specifications  of  the  contract  under  which  they 
were  procured.  PAT&E  involves  two  different  types  of  test  programs. 
BIS  trials  proceed  under  the  sponsorship  and  direction  of  the  President 
of  the  Board  of  Inspection  and  Survey  (PRESINSURV)  and  are  conducted  on 
ships  and  aircraft  only.  In  the  case  of  aircraft,  only  the  first  physi¬ 
cal  and  functional  equivalents  of  a  model  or  type  are  subject  to  BIS 
trials;  however,  each  and  every  ship  delivered  under  a  production  con¬ 
tract  is  subject  to  the  trials.  Government  acceptance  tests  (GATs)  are 
conducted  on  items  other  than  aircraft  and  ships.  GATs  include  the 
factory  acceptance  tests  (FATs)  performed  on  each  article  and  conducted 
under  the  supervision  of  the  local  plant  representative,  and  the  produc¬ 
tion  monitoring  tests  (PMTs)  conducted  by  SYSCOM-designated,  indepen¬ 
dent,  industrial  or  government  activities. 

Test  and  Evaluation  Master  Plan  (TEMP) 

The  TEMP  required  by  DODD  5000.3  and  0PNAV1NST  3960.10  is  recog¬ 
nized  throughout  the  test  community  as  the  controlling  management  docu¬ 
ment  dealing  with  identification  and  integration  of  the  objectives, 
responsibilities,  methodologies,  resources,  and  schedules  for  all  as¬ 
pects  of  T&E.  The  principal  features  of  the  TEMP  are  summarized  in 
Figure  4-21.  It  is  intended  by  OP-098  that  the  TEMP  is  to  be  a  short, 
directive  document,  and  that  for  ACAT  III  and  IV  programs,  it  is  to  be 
the  program  controlling  document. 

The  TEMP  results  from  collaboration  between  the  PM,  0PTEVF0R  (or 
the  Marine  Corps  Operational  Test  and  Evaluation  Activity  (MC0TEA))  and, 
in  the  acquisition  of  ships  and  aircraft,  the  BIS.  Inputs  should  also 
be  solicited  from  the  concept  developer(s)  as  well  as  from  reliability, 
maintainability,  and  QA  personnel.  The  need  for  close  and  continued 
cooperation  with  0PTEVF0R  in  the  development  and  execution  of  the  TEMP 
is  essential.  As  the  Navy's  independent  T&E  agency,  0PTEVF0R  determines 
the  operational  effectiveness  and  operational  suitability  of  the  devel¬ 
oped  system. 
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DEFINITION: 

FUNCTIONS: 

RESPONSIBILITIES: 


CONTAINS: 


CONTROLLING  T&E  MANAGEMENT  DOCUMENT  FOR  ACAT  I,  II, 
III  AND  IV  PROGRAMS 

TO  CONTROL  ACCOMPLISHMENT  OF  ADEQUATE  TAE 
TO  IDENTIFY  NECESSARY  T&E  RESOURCES 
TO  FACILITATE  PLANNING,  PROGRAMMING,  BUDGETING 
TO  MINIMIZE  FLEET  ROT&E  SUPPORT  REQUIREMENTS 

PROJECT  MANAGER  PREPARES  IN  COOPERATION  WITH 
OPTEVFOR 

OPNAV  APPROVES  ALL  TEMPS  FOR  ACAT  II  &  III;  REVIEWS 
AND  FORWARDS  TEMPS  FOR  ACAT  I  TO  OSD 
SYSCOM  COMMANDER  AND  COMOPTEVFOR  APPROVES  TEMPS  FOR 
ACAT  IVT;  SYSCOM  COMMANDER  APPROVES  TEMPS  FOR 
ACAT  IVM 

SYSTEM  DESCRIPTION/ INTENDED  OPERATIONAL  MISSION 
CRITICAL  TAE  ISSUES,  EXPANDED  FOR  DCP 
PROJECT  OBJECTIVES  AND  THRESHOLDS 
FLEET  TEST  RESOURCES  REQUIRED,  STRIKE  AIRCRAFT, 
RANGE.  ETC. 

REQUIRED  TECHNICAL  AND  OPERATIONAL  CHARACTERISTICS 
PLANNED  DT  &  OT 
INTEGRATED  SCHEDULE  FOR: 

CONTRACTOR  DEMONSTRATIONS 

PRELIMINARY  EVALUATIONS 

TECHEVAL/OPEVAL 

APPROVAL  FOR  FULL  PRODUCTION 

REQUIRED  "STANDARD"  DTAE/0T&E/M1  LESTONES 


FIGURE  4-21.  Principal  Features  of  the  TEMP. 


The  PM  must  prepare  the  TEMP  early  in  the  acquisition  program. 
The  TEMP  will  be  signed  by  COMOPTEVFOR  and  the  SYSCOM  Commander  (or  CNM) 
and  forwarded  to  the  OPNAV  sponsor,  approved  by  OP-098  and  distributed. 
The  initial  version,  necessarily  lacking  in  many  planning  details,  must 
be  approved  by  OPNAV  prior  to  Milestone  I.  This  approval  constitutes 
CNO  direction  to  conduct  the  T&E  program  and  commits  fleet  support.  For 
ACAT  I  and  Joint  Service  programs  the  TEMP  is  forwarded  to  the  Director 
Defense  Test  and  Evaluation  (DDT&E)  in  OSD  for  approval  prior  to  each 
DSaRC. 


Test  Planning 

Comprehensive  and  objective  testing  is  a  goal  of  everyone  involved 
in  the  acquisition  process, and  its  achievement  will  be  facilitated  by 
careful,  timely  planning  and  budgeting.  Test  plans  will  be  based  di¬ 
rectly  on  the  TEMP  by  the  development  activity  (for  DT&E  and  develop¬ 
ment-activity-conducted  PAT&E) ,  by  COMOPTEVFOR  (for  OT&E),  and,  when 
appropriate,  by  PRESINSURV  (for  BIS  PAT&E).  These  test  plans  will  be 
consistent  with  the  TEMP  and  adequate  to  carry  out  its  provisions. 

Frequently  overlooked  among  the  inputs  to  T&E  planning  is  the  need 
to  obtain  accurate  information  on  the  anticipated  threat-and-use  envi¬ 
ronment.  The  development  of  a  life  profile,  system-use  profile,  or 
factory-to-target  sequence  (see  the  critical  topic  entitled  "Designing 
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for  the  Environment")  in  which  inputs  from  the  logistics  and  mission 
profiles  are  integrated  is  valuable  in  this  regard. 

For  ACAT  I  programs,  before  DSARC  II  is  reached,  the  PM,  in  coor¬ 
dination  with  the  program  team  and  the  appropriate  test  agencies  (e.g., 
OPTEVFOR),  must  ensure  that: 

1.  Test  objectives  are  established  and  understood 

2.  Test  criteria  are  determined  and  understood 

3.  Test  methods  are  defined  and  understood 

4.  Funds  are  allocated  to  support  development  of  an  adequate, 
simulated,  threat-and-use  environment  with  appropriate  range- 
instrumentation  and  data  processing  capabilities. 


Joint  Service  Testing 

Two  types  of  joint  service  testing  have  emerged  through  usage.  The 
first,  not  normally  applied  to  an  acquisition  program,  is  usually  joint 
T&E  (JT&E).  JT&E  is  OSD  directed  and  partially  funded,  non-acquisition 
T&E  structured  to  evaluate  system  operational  or  technical  performance 
under  realistic  conditions  with  more  than  one  service  participating  or 
with  interrelated/interacting  systems.  JT&E  is  normally  initiated  and 
coordinated  by  DDT&E  with  one  of  the  services  delegated  detailed  manage¬ 
ment  responsibility.  For  initial  planning  (prior  to  assignment  of  a 
lead  service),  OP-098  serves  as  the  Navy  point  of  contact  with  DDT&E  on 
JT&E  matters. 

The  second  type  of  joint  service  testing,  usually  relating  to 
system  acquisition,  is  often  called  multi-service  T&E  (MST&E) .  MST&E  is 
the  T&E  conducted  jointly  by  two  or  more  services  for  systems  to  be 
acquired  by  more  than  one  service  or  for  a  service's  system  that  has  to 
interface  with  another  service's  equipment.  It  may  include  either  or 
both  DT&E  and  OT&E  objectives. 

When  the  Navy  is  the  lead  (executive)  service,  MST&E  will  be  con¬ 
ducted  as  outlined  in  OPNAVINST  3960.10.  When  another  service  (or 
agency)  is  the  lead,  MST&E  will  be  conducted  in  accordance  with  its  T&E 
regulations  and  procedures. 

Deviation  from  the  T&E  regulation  of  the  lead  service  may  be  imple¬ 
mented  by  written  agreement  between  the  involved  services.  Also,  tests 
conducted  by  a  single  service,  usually  done  for  its  own  unique  require¬ 
ment,  will  be  conducted  under  its  own  regulations. 
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FIGURE  4-22,  Sheet  2  of  9.  Controlling  Document  List 
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FIGURE  4-22,  Sheet  3  of  9.  Controlling  Document  List. 
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FIGURE  4-22,  Sheet  4  of  9.  Controlling  Document  List 
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FIGURE  4-22,  Sheet  5  of  9.  Controlling  Document  List 
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FIGURE  4-22 4  Sheet  8  of  9.  Controlling  Document  List. 
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_ Appendix  A 

SYSTEMS  ACQUISITION  IN  THE  NAVY 


Appendix  A 

THE  DEPARTMENT  OF  THE  NAVY  ACQUISITION  PROCESS 


ACQUISITION  POLICY  -  DEPARTMENT  OF  DEFENSE  (POD) 

Acquisition  policy  as  stated  in  DODD  5000,1  is  as  follows: 

a.  It  is  the  policy  of  the  Department  of  Defense  to  ensure  that 
DOD  acquisition  of  major  defense  systems  is  carried  out  efficiently  and 
effectively  to  achieve  operational  objective-,  of  the  U.S.  Armed  Forces 
in  their  support  of  national  policies  and  objectives,  and  that  it  meets 
the  guidelines  of  reference  (b)  (0MB  Circular  A- 109). 

b.  Management  responsibility  for  system  acquisition  programs 
shall  be  decentralized  except  for  the  decisions  specifically  retained  by 
the  Secretary  of  Defense. 

c.  The  management  principles  and  objectives  in  this  Directive 
(DODD  5000.1)  shall  be  applied  to  the  acquisition  of  defense  system  not 
designated  as  major. 


ACQUISITION  POLICY  -  DEPARTMENT  OF  THE  NAVY  (DON) 

Basic  policy  for  systems  acquisition  within  the  DON  is  promulgated 
by  the  Secretary  of  the  Navy  (SECNAV)  in  SECNAVINST  5000.1  which  states 
that  system  acquisitions  carried  out  to  achieve  the  operational  objec¬ 
tives  of  the  Navy  and  Marine  Corps  are  to  be  managed  efficiently  and 
effectively  by: 

o  Streamlining  administrative  procedures,  such  as  eliminating 
redundant  review  and  documentation  requirements;  and  schedul¬ 
ing  milestone  reviews  early  enough  to  avoid  gaps  between 
phases; 

o  Delegating  management  responsibilities  to  the  lowest  level 

possessing  a  total  view  of  the  program.  Responsibilities  and 
accountability  are  to  be  clearly  established  and  commensurate 
resources  provided; 

o  Correlating  the  overall  Planning,  Programming  and  Budgeting 
System  (PPBS)  priority  and  status  with  individual  program 
decisions;  ensuring  affordability  of  programs;  and  controlling 
cost  growth  within  programs-, 

o  Tailoring,  for  each  program,  an  acquisition  strategy  encom¬ 

passing  all  internal  and  external  elements  of  the  acquisition 
process,  including  early  integration  of  manpower,  training  and 
logistic  support; 

o  Pursuing  readiness  and  sustainability  based  on  realistic  oper¬ 
ational  availability  thresholds  as  primary  objectives,  equal 
in  priority  with  achieving  specified  performance  levels,  from 
the  start  of  a  program; 
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o  Increasing  program  stability  by  developing  improved  long  range 
plans;  realistic  budget  and  cost  estimates:  economical  produc¬ 
tion  rates;  and,  when  appropriate,  by  multiyear  contracting; 

o  Applying  established  or  evolving  technology  having  a  high 

probability  of  success.  High  technical  risks  may  be  taken  if 
an  extraordinary  pay-off  potential  can  be  demonstrated; 

o  Making  well-balanced  trade-offs  between  life-cycle  costs, 

system  effectiveness,  and  time  between  program  initiation  and 
approval  for  production; 

o  Strengthening  the  industrial  base  and  improving  productivity; 
and 

o  ,  Judiciously  applying  the  following  management  considerations: 


MANAGEMENT  CONSIDERATIONS 

1.  ACQUISITION  STRATEGY.  From  program  start,  an  overall  plan  to 
acquire,  produce  and  support  the  system  shall  be  developed  and  tailored 
to  the  unique  circumstances  of  the  program.  It  shall  set  forth  the 
objectives,  resources,  principal  assumptions  and  contracting  approach, 
including  extent  of  competition.  For  ACAT  I  programs,  the  exceptions 
under  0MB  Circular  A-109,  Sections  llj,  12b,  12c  or  13c  (NOTAL)  may  be 
invoked,  when  appropriate.  The  acquisition  strategy  shall  be  executed 
with  maximum  tailoring,  flexibility,  innovation  and  common  sense. 

2.  AFFORDABILITY.  At  each  decision  point,  it  shall  be  demonstra¬ 
ted  that  the  program,  as  recommended,  is  affordable,  by  assessing  pro¬ 
gram  cost  against  program  priority  and  available  resources  as  establish¬ 
ed  in  the  PPBS  process.  Programs  not  funded  at  a  level  adequate  for 
full  program  execution  shall  be  considered  for  termination.  In  between 
milestones,  affordability  is  reassessed  as  part  of  the  PPBS  process; 
however,  programmatic  issues  raised  and  decisions  made  at  the  last 
milestone  shall  not  be  readdressed.  If  any  proposed  PPBS  action  differs 
from  the  last  milestone  decision,  the  decision  authority  shall  be  noti¬ 
fied  promptly;  and  if  it  may  cause  a  threshold  breach  for  ACAT  I  or  ACAT 
IIS  programs,  SECNAV  approval  is  required. 

3.  ACQUISITION  TIME.  Programs  shall  be  planned  for  system  devel¬ 
opment  within  the  shortest  time  reasonable.  At  each  milestone,  schedule 
alternatives  and  inherent  risks  shall  be  assessed.  Methods  to  be  con¬ 
sidered  include  combination  or  omission  of  acquisition  phases;  smooth 
transition  to  production;  single  concept  development;  preplanned  product 
improvement;  use  of  alternatives  in  high  risk  areas;  experimental  proto¬ 
typing  or  critical  components;  or  coordination  of  common  purchases 
between  different  programs. 

4.  COST  ESTIMATING.  Current  life  cycle  cost  estimates  shall  be 
prepared  for  each  milestone.  Successive  cost  estimates  shall  be  trace¬ 
able  from  Milestone  I,  including  reasons  for  inflation  adjustments  and 
cost  growth. 
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5.  OPERATIONAL  CONCEPT.  The  operational  concept  shall  initially 
be  developed  at  Milestone  I,  finalized  by  Milestone  II  and  maintained 
throughout  the  program  and  addressed  in  the  milestone  documentation. 

6.  PRODUCTION  PLANNING.  From  the  early  phases,  producibility  of 
the  design  shall  be  a  major  consideration. 

7.  MANPOWER  AND  TRAINING.  Systems  shall  be  designed  to  minimize 
the  number,  skills  and  occupations  required  for  operation  and  support. 
Trade-off  studies  shall  be  made  among  manpower  (numbers  and  skill  le¬ 
vels),  support  structure  and  equipment  and  system  design.  Manpower  and 
training  requirements  shall  be  considered  from  program  start  and  devel¬ 
oped  in  detail  by  Milestone  III. 

8.  LOGISTICS  SUPP0RTA8ILITY.  Logistics  support abi lity  shall  be  a 
design  requirement  as  important  as  cost,  schedule  and  performance,  and 
established  as  required  by  DODD  5000. 39of  17  January  1980  (enclosed  in 
SECNAVINST  5000.39  (NOTAL). 

9.  STANDARDIZATION.  Intraservice/interservice  standardization 
and  interoperability  requirements  shall  be  considered.  System  design 
shall  make  optimum  use  of  existing  subsystems,  components,  parts  and 
materials  common  to  other  available  systems.  However,  essential  perfor¬ 
mance  requirements  should  not  be  compromised  thereby,  nor  should  appli¬ 
cation  of  new  technology  or  innovative  design  be  inhibited. 

10.  TEST  AND  EVALUATION.  Test  and  evaluation  are  an  Integral  part 
of  the  acquisition  process  to  assess  technical  performance  and  risks, 
and  operational  effectiveness  and  suitability  of  a  system.  An  efficient 
mix  of  analyses,  simulations  and  laboratory  tests  prior  to  field  tests 
will  be  applied  In  the  order  listed  so  that  preceding  evaluations  ade¬ 
quately  bound  and  eliminate  unnecessary  field  testing.  For  ACAT  I 
programs,  references  (a),  (b)  and  (c)  (DODD  5000.1,  D0DI  5000.2  and  DODD 
5000.3  respectively)  apply.  For  ACAT  IIS  programs,  the  policies  of 
reference  (c)  apply,  and  a  Test  and  Evaluation  Master  Plan  (TEMP)  shall 
be  developed  for  Milestone  I  and  maintained  throughout.  Including  Fol¬ 
low-on  Operational  Test  and  Evaluation  (FQT&E).  Schedules  shall  be 
flexible  to  allow  retest  or  reevaluation  as  necessary  prior  to  a  mile¬ 
stone,  and  shall  avoid  duplication  commenserate  with  risk. 

11.  SOURCES.  All  capable  entities,  private  or  governmental, 
should  be  fully  considered,  small  and  disadvantaged  business  organiza¬ 
tions,  DON,  Army  or  Air  Force  activities,  federally-funded  R&D  Centers, 
not-for-profit  organizations,  colleges  and  universities.  In  particular, 
DON  R&D  Centers  should  be  considered  for  development  within  their  as¬ 
signed  function  during  all  program  phases  with  appropriate  contractor 
support. 


12.  COMPETITION.  As  long  as  practicable,  competition  shall  be 
sought  in  a  creative  manner,  and  maintained  throughout  the  acquisition 
cycle.  At  each  milestone,  plans  for  enhancing  competition  shall  be 
described,  such  as  competitive  teaming,  direct  licensing,  leader  company 
procurement,  or  component  breakout.  At  Milestone  II,  it  should  be 
determined  whether  to  acquire  a  design  disclosure  package  of  an  end 
product  drawings/specifications  enabling  competition. 


13.  CONTRACTING  OUT.  Functions  of  a  policy/decision  making  or 
managerial  nature  which  are  the  direct  responsibility  of  DON  officials 
shall  not  be  performed  by  DON  employees.  While  advice  may  be  properly 
obtained  by  contract,  contractor  performance  of  basic  management  func¬ 
tions  begins  when  contractor  involvement  is  so  extensive  that  it  limits 
the  DON  ability  to  develop  options  other  than  proposed  by  he  contractor. 

14.  ACQUISITION  RISKS.  Technical,  operational,  schedule,  and  cost 
risks  shall  be  identified  as  early  as  possible  and  assessed  continuous¬ 
ly.  They  shall  be  disclosed  in  full  to  the  decision  authority  and 
addressed  realistically  at  each  milestone.  A  management  reserve  based 
on  the  cost  risk  shall  be  established  for  ACAT  I  and  IIS  programs. 
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While  it  is  virtually  impossible  to  describe  all  the  steps  in  the 
acquisition  process,  the  following  pages  describe,  in  the  form  of  des¬ 
criptive  paragraphs  and  facing-page  flow  charts,  the  major  steps  in  the 
DON'S  acquisition  process  for  the  various  types  of  programs,  i.e., 
Acquisition  Categories  (ACATs).  The  description  identifies  the  various 
officials  and  special  groups  involved,  the  documentation  used  and 
the  review  and  approval  process. 

When  appropriate,  a  "NOTE"  is  added  to  the  end  of  a  paragraph  to 
highlight  options  for  the  action  called  for  in  the  paragraph  or  to 
provide  some  insight  into  the  action  described. 

In  the  case  where  an  acquisition  documents  or  a  review  groups  is 
mentioned  in  the  description  that  follows  and  are  also  described  in  the 
body  of  the  GUIDE,  an  appropriate  page  reference  is  provided. 


A-5 


ACQUISITION  PROCESS  OUTLINE 
PROGRAM  INITIATION 


1.  Inputs  for  Navy  needs  may  be  submitted  to  Office  of  the  Chief  of 
Naval  Operations  (OPNAV)  sponsors  by  Deputy  Chiefs  of  Naval  Opera¬ 
tions/Directors  of  Major  Staff  Offices  (DCNOs/  DMSOs),  Fleet  Com¬ 
manders  in  Chief  (CINCs)  or  others. 

2.  When  the  need  for  a  new  system  is  perceived  and  is  believed  to  be 
affordable,  a  draft  Tentative  Operational  Requirement  (TOR)  (see 
page  2-1)  is  originated  by  the  OPNAV  sponsor. 

3.  The  draft  TOR  is  forwarded  for  comment  to  Fleet  CINCs,  selected 
offices  within  OPNAV,  Commander,  Operational  Test  and  Evaluation 
Force  (COMOPTEVFOR)  and  others  as  appropriate. 

4.  Based  on  the  comments  received,  the  OPNAV  sponsor  revises  the  draft 
TOR  as  necessary. 

5.  The  TOR  is  submitted  to  the  Office  of  Naval  Warfare  (OP-095)  for 
review  and  approval.  TORs  for  strategic  nuclear  systems  are  sub¬ 
mitted  to  the  DC NO  (Plans,  Policy  and  Operations)  (OP-06)  for  ap¬ 
proval  . 

NOTE:  TORs  may  be  issued  at  any  time  in  the  annual  cycle.  A 

rule  of  thumb,  for  planning  purposes,  is  that  the  TOR 
should  be  issued  about  a  year  in  advance  of  the  Program 
Objectives  Memorandum  (POM)  submission  which  will  contain 
the  initial  funding. 

6.  Once  approved  by  OP-095,  the  TOR  is  promulgated  by  the  Office  of 
the  Director,  Research,  Development,  Test  and  Evaluation  (OP-098) 
and  forwarded  to  the  Chief  of  Naval  Material  (CHNAVMAT).  CilNAVMAT 
in  turn  assigns  it  to  the  appropriate  Systems  Command  (SYSCOM) 
commander  or  CHNAVMAT  designated  program  manager  (PM).  The  SYSCOM 
commander  or  PM,  on  receipt  of  the  TOR,  explores  the  options  ade¬ 
quately,  interfacing  with  Navy  laboratories,  industry  and  COMOPTEV¬ 
FOR  as  appropriate,  to  produce  a  Development  Options  Paper  (DOP) 
(see  page  2-1)  which  describes  a  range  of  possible  systems  covering 
a  spectrum  of  capabilities. 
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7.  The  DOP  is  transmitted  to  the  OPNAV  sponsor  via  CHNAVMAT  with 
copies  to  selected  OPNAV  offices,  COMOPTEVFOR  and  others  as  appro¬ 
priate.  The  OPNAV  sponsor  selects  the  alternative  which  best 
matches  the  desired  capabilities  with  affordability  considerations. 
Based  on  this  selection  the  OPNAV  sponsor  originates  an  Operational 
Requirement  (OR)  (see  page  2-1)  defining  the  major  characteristics 
of  the  selected  system.  For  potential  DOD  major  programs  (ACAT  I), 
a  Justification  for  a  Major  System  New  Start  (JMSNS)  (see  page  2-2) 
is  prepared  in  lieu  of  an  OR. 

8.  The  QR/JMSNS  is  routed,  via  DCNO  (Manpower,  Personnel  and  Training) 

(QP-01),  DCNO  (Logistics)  (OP-04)  and  the  Plans  and  Programs  Office 
(0P-090),  to  OP-095  for  review  and  approval.  High-cost  or  contro¬ 
versial  programs  must  be  concurred  in  by  Chief  of  Naval  Opera¬ 
tions/  Vice  Chief  of  Naval  Operations  (CNO/VCNO)  prior  to  approval 
of  the  OR/ JMSNS.  0P-090  decides  whether  this  approval  is  accomp¬ 

lished  by  the  CNO  Executive  Board/Acquisition  Review  Committee/Ship 
Characteristics  Improvement  Board  (CEB/ARC/SCIB)  (see  page  2-35)  or 
directly  by  OP-095.  For  strategic  nuclear  systems,  the  OR/JMSNS  is 
reviewed  and  approved  by  CP-06. 

9.  Once  approved,  the  OR/JMSNS  is  promulgated  by  OP-098  to  CHNAVMAT 

with  copies  to  all  appropriate  commands  and  offices.  CHNAVMAT 

assigns  the  OR/JMSNS  to  the  appropriate  SYSCOM  commander  or  CHNAV¬ 
MAT  designated  PM  who  will  initiate  planning  for  the  program  de¬ 
scribed  in  the  OR/JMSNS. 

NOTE:  ORs/JMSNSs  may  be  issued  at  any  time.  However,  if  a  new 

start  is  to  be  included  in  the  POM  submission  in  May,  the 
OR/JMSNS  must  be  promulgated  by  the  preceding  1  February. 
This  will  allow  about  two  months  for  OPNAV  and  Secretary 
of  the  Navy  (SECNAV)  review  of  the  requirement  and  the 
proposed  program  prior  to  the  final  POM  decision  on 
funding. 

NOTE:  When  a  Navy  POM  with  a  JMSNS  for  a  new  major  program  is 

submitted  to  the  SECDEF  for  approval,  the  SECDEF  denotes 
his  approval  in  the  Program  Decision  Memorandum  (RDM). 
When  a  program  represented  by  a  JMSNS  is  modified  by  the 
SECDEF,  the  changes  are  documented  in  a  SECDEF  Decision 
Memorandum  (SDDM)  (see  page  2-33). 

NOTE:  If,  subsequent  to  approval  of  an  OR/JMSNS,  the  resulting 

program  is  not  funded  in  the  first  or  second  year  of  the 
next  POM,  the  OR/JMSNS  is  canceled  by  OP-098. 
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ACQUISITION  PROCESS  OUTLINE 
MILESTONES  I,  II  &  III 

10  Once  a  program  has  made  sufficient  progress  to  allow  it  to  enter 
into  the  next  phase  of  acquisition  and  the  development  and  opera¬ 
tional  test  reports  are  available,  the  PM  prepares  or  revises  the 
necessary  milestone  decision  review  documents.  For  AC AT  I  programs 
these  are  a  System  Concept  Paper  (SCP)  (see  page  2-32)  and  Test  and 
Evaluation  Master  Plan  (TEMP)  (see  pace  2-32), 
a  Decision  Coordinating  Paper  (DCP)  (see  page  2-50) and  TEMP  for 
Milestones  II  and  III.  For  an  ACAT  IIS  and  ACAT  HC,  the 
documents  are  a  Navy  Decision  Coordinating  Paper  (NDCP)  (see  page 
2-32)  and  TEMP  for  all  milestones.  For  ACAT  III  and  ACAT  IV  pro¬ 
grams,  the  decision  document,  for  all  milestones,  Is  the  TEMP,  in 
addition  all  program  require  the  preparation  of  an  Approval  for 
Production  action  sheet  for  the  Milestone  III  review..  Based  on 
these  documents  the  PM  prepares  his  Milestone  Review  Presentation. 
The  SCP/DCP/NDCP/TEMP  are  forwarded  by  the  PM,  through  the  chain- 
of -command,  to  the  appropriate  decision  authority  level  for  staff 
review/recommendations  prior  to  the  milestone  decision  review. 

NOTE*  For  ACAT  I  programs,  at  Milestones  II  and  III,  SECDEF  may 
require  some  elements  of  the  Integrated  Program  Summary 
(IPS)  (see  page  2-50)  as  backup  for  the  information  con¬ 
tained  in  the  DCP. 

NOTE:  ACAT  III  and  ACAT  IV  programs  do  not  normally  have  a 

Milestone  I.  However,  a  TEMP  is  required  at  the  approxi¬ 
mate  time  of  Milestone  I  (near  the  beginning  of  the  first 
fiscal  year  containing  program  funding). 

11.  The  PM  qives  his  Milestone  Review  Presentation  to  the  SYSCOM  Acqui¬ 
sition  Review  Board  (ARB)  (see  page  2-36).  If  the  ARB  is  in  agree¬ 
ment  that  the  program  is  ready  to  enter  the  next  phase,  it  so 
reconmends  to  the  CHNAVMAT .  For  ACAT  IV  programs.  Systems  Command 
Commander  (SYSCOM  CDR)  approval  of  such  an  ARB  recommendation  and 
the  documentation  of  that  decision  in  a  SYSCOM  CDR  decision  memo¬ 
randum  provides  the  PM  with  the  necessary  go-ahead  to  proceed  with 
the  next  acquisition  phase. 


NOTE:  For  ACAT  IVT  programs,  if  C0M0PTEVF0R  and  the  SYSCOM  dis¬ 

agree,  CHNAVMAT  is  the  decision  maker. 

For  ACAT  III  programs,  after  CHNAVMAT  approval,  the  PM‘s  Milestone 
Review  Presentation  is  forwarded  to  the  OPNAV  sponsor  who  convenes 
a  Sponsor's  Program  Review  (SPR)  (see  pag©  2-35)*  At  the  conclu- 
sion  of  the  SPR,  the  OPNAV  sponsor  drafts  the  SPR  decision  document 
(see  page  2-33).  After  review  of  the  draft  by  0P-090,  OP-098  and 
OP-04,  the  SPR  decision  document  is  approved  and  promulgated  by  the 
OPNAV  sponsor.  The  approved  SPR  decision  document  provides  the 
necessary  authority  for  the  PM  to  proceed  with  the  next  phase. 

NOTE:  If  there  are  significant  disagreements  as  to  what  the 

recommendation  should  be,  they  are  resolved  by  0P-090. 
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13-  For  ACAT  IIC  programs,  after  CHNAVMAT  approval,  the  PM's  Milestone 
Review  Presentation  is  forwarded  to  the  OPNAV  Sponsor  who  submits 
it  to  the  ARC  or  SC IB  for  review  and  recommendations.  The  ARC  or 
SCIB  recommendations  are  submitted  to  the  CNO  for  review  and  appro¬ 
val.  A  favorable  recommendation  to  and  approval  by  the  CNO  docu¬ 
mented  in  a  CNO  decision  memorandum  provides,  for  ACAT  IIC  pro¬ 
grams,  the  PM  with  the  authority  to  enter  the  next  phase  of  the 
acquisition  process. 

14.  For  ACAT  IIS  programs,  after  CHNAVMAT  approval  of  the  PM's  Mile¬ 
stone  Review  Presentation,  the  Presentation  is  given  to  the  CEB 
and,  with  CNO  approval.  Is  given  to  the  Department  of  the  Navy 
Systems  Acquisition  Review  Council  (DNSARC)  (see  page  2-34).  The 
DNSARC  recommendations  are  submitted  to  the  SECNAY  for  review  and 
approval.  A  favorable  recommendation  to  and  approval  by  the  SEC- 
NAV,  documented  in  a  SECNAV  decision  memorandum  (SNDM)  (see  page 
2-33)  provides,  for  ACAT  IIS  programs,  the  PM  with  the  authority  to 
enter  the  next  phase  of  the  acquisition  process. 

15.  For  ACAT  I  programs,  the  CHNAVMAT,  CNO  and  SECNAV  approved  PM's 
Milestone  Review  Presentation  is  submitted  to  the  Defense  Systems 
Acquisition  Review  Council  (DSARC)  (see  page  2-34)  for  review.  The 
DSARC  recommendations  are  submitted  to  the  SECDEF  for  review  and 
approval.  A  favorable  DSARC  recommendation  and  Secretary  of  De¬ 
fense  (SECDEF)  approval,  documented  in  an  SDDM,  provides  the  PM, 
for  ACAT  I  programs,  the  authority  to  enter  the  next  phase  of  the 
acquisition  process. 

NOTE:  Normally  the  Milestone  III  decision  for  an  ACAT  I  program 

is  delegated,  by  the  SECDEF,  to  the  SECNAV  unless  the 
thresholds  established  at  Milestone  II  are  breached. 
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The  PPBS  can  be  summarized  in  a  few  words.  Based  on  the  anticipat¬ 
ed  THREAT,  a  STRATEGY  is  developed.  In  support  of  that  strategy,  force 
REQUIREMENTS  are  developed.  Based  on  those  requirements,  PROGRAMS  are 
developed  to  provide,  on  an  orderly  basis,  weapons  systems  and  manpower 
over  a  period  of  time,  with  due  consideration  of  the  total  cost  to  the 
nation.  Lastly,  funds  must  be  BUDGETED  in  such  a  manner  as  to  obtain 
the  required  forces  and  weapon  systems  within  the  resources  that  the 
nation  provides. 

The  PPBS  process,  so  briefly  outlined  above,  is  presented  on  the 
following  pages  in  the  form  of  descriptive  paragraphs  and  facing  page 
flow  charts.  The  PPBS  cycle  shown  is  for  the  Fiscal  Year  1986  budget 
which  started  in  August  of  1983  and  ends  in  September  1985.  Where 
appropriate,  a  NOTE  has  been  added  to  the  end  of  certain  descriptive 
paragraphs  to  indicate  that  there  are  options  to  the  action  called  for 
in  that  paragraph  or  to  provide  some  other  insight  into  the  action 
described. 


The  charts  necessarily  show  the  process  as  a  progression  of  the 
major  steps  as  it  proceeds  from  initial  high-level  strategic  decisions 
and  guidance  to  the  final  submission  by  the  Secretary  of  Defense  (SEC- 
DEF)  of  the  Department  of  Defense  (DOD)  budget.  This  should  not  be 
interpreted  to  mean  that  the  PPBS  is  linear  in  operation.  As  shown 
below,  the  budgets  for  three  fiscal  years  are  always  simultaneously  in 
work  at  different  stages  of  the  cycle.  Iterative  information  flows 
continuously  in  both  directions,  both  within  and  between  cycles. 
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PLANNING  PHASE  (August  1983  to  early  October  1983) 


1.  In  August,  the  Commanders  of  the  Unified  and  Specified  Commands 
( C INCs)  prepare  their  personal  recommendations  for  major  changes  in 
the  previous  Defense  Guidance  (DG). 

2.  In  late  August,  the  CINCs'  recommendations  are  furnished  to  the 
Secretary  of  Defense  (SECDEF).  After  submittal,  the  Joint  Chiefs 
of  Staff  (JCS)  and  the  CINCs  meet  with  the  Defense  Resources  Board 
(DRB)  to  review  and  assess  their  recommendations. 

3.  In  late  August/early  September,  various  organizations  provide 
major  DG  issues  to  the  planning  process  to  the  SECDEF.  These 
include;  the  Joint  Strategic  Planning  Document  (JSPD)  from  the 
Organization  of  the  JCS  (OJCS);  major  Issues  which  the  Department 
of  Defense  (DOD)  Components  wish  to  have  considered  during  the 
development  of  the  DG;  and  other  references  pertinent  to  the  devel¬ 
opment  of  Policy,  Strategy  and  Force  Planning  sections  of  the  DG. 

4.  At  this  time,  the  Secretary  of  the  Navy  (SECNAV)  Issues  the  Depart¬ 
ment  of  the  Navy  Policy  and  Planning  Guidance  (DNPPG)  which  pro¬ 
vides  top  level  broad  guidance  for  Navy  planning. 

NOTE;  Part  of  the  DNPPG  is  used  by  the  Navy  to  provide  input 

for  the  major  DG  Issues  in  Step  3  above, 

5.  In  September,  based  on  the  DRB  assessment  of  the  CINCs'  recommenda¬ 
tions  and  the  other  key  inputs,  the  Office  of  the  Under  Secretary 
of  Defense,  Policy  (OUSD(P) )  develops,  in  coordination  with  the 
staffs  of  the  DOD  Components,  the  OJCS  and  the  Office  of  the  SECDEF 
(OSD),  a  "For  Comment"  draft  of  the  Policy  Guidance  section  of  the 
Threat  Assessment,  Policy,  Strategy  and  Force  Planning  part  of  the 
DG. 

6.  In  September,  based  on  the  DNPPG  guidance,  the  Office  of  the 

Chief  of  Naval  Operations  (OPNAV)  prepares  the  Chief  of  Naval 

Operations  Policy  and  Planning  Guidance  (CPPG)  setting  forth  the 
strategy  to  be  used  in  formulating  Navy  programs.  The  CPPG  is 
issued  after  review  and  approval  by  the  Chief  of  Naval  Operations 
(CNO) . 

7.  In  early  October,  the  OUSD(P)  provides  the  For  Comment  draft 

Policy  Guidance  section  of  the  DG  to  the  DOD  Components,  the  CINCs, 
the  staff  of  the  National  Security  Council  (NSC),  the  Department  of 
State  and  the  Office  of  Management  and  Budget  (0MB )  for  review  and 
comment . 


B-2 


PLANNING  PHASE  continued  (mid-October  1983  to  early  November  1983) 


8.  Before  mid-October,  the  various  comments  are  submitted  to  the 
OUSD(P) .  Where  possible,  issues  raised  by  the  comments  are  resol¬ 
ved  between  the  various  staffs  and  Incorporated  in  an  updated 
Policy  Guidance  section  of  the  DG.  Other  Issues  are  identified  as 
requiring  DRB  review  and  resolution. 

9.  In  late  October,  the  DRB  meets  to  resolve  the  remaining  issues 
and  to  review  and  approve  and/or  modify  the  updated  Policy  Guidance 
section  of  the  DG. 

10.  In  late  October,  the  OUSD(P)  revises,  as  necessary,  the  updated 
Policy  Guidance  section  of  the  DG. 

11.  From  October  to  January,  based  on  the  CPPG,  OPNAV  prepares  and 
submits  Chief  of  Naval  Operations  Program  Analysis  Memoranda 
(CPAMs ) ,  Naval  Warfare  Appraisals  and  other  information  to  the 
Chief  of  Naval  Operations  Executive  Board  (CEB)  which  formulates 
recommendations  for  the  CNO. 

12.  In  September/October  1983,  the  Under  Secretary  of  Defense,  Re¬ 
search  and  Engineering  (USDR&E)  and  the  Office  of  the  Assistant 
Secretary  of  Defense,  Manpower,  Reserve  Forces  and  Logistics  (ASD- 
(MRA&L) ),  in  coordination  with  the  Office  of  the  Assistant  Secre¬ 
tary  of  Defense,  Comptroller  (OASD(C)),  the  Office  of  the  Director, 
Program  Analysis  and  Evaluation  (ODPA&E)  and  the  staffs  of  the  DOD 
Components,  the  OJCS  and  the  OSD,  prepare  a  draft  Resources  Plan¬ 
ning  Guidance.  At  the  same  time,  the  OASD(C)  and  the  ODPA&E  pre¬ 
pare  a  Tentative  Fiscal  Guidance. 

13.  In  early  November,  the  draft  Resource  Planning  Guidance  and  the 
Tentative  Fiscal  Guidance  are  forwarded  to  the  OUSD(P).  Based  on 
these  documents  and  the  revised  Policy  Guidance  section  of  the  DG, 
the  OUSD(P)  prepares  the  draft  DG. 
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PLANNING  PHASE  continued  (early  November  1933  to  early  December  1983) 


14.  In  early  November,  the  Draft  DG  is  provided  to  the  DOD  Compo¬ 
nents,  the  CINCs,  the  NSC  staff,  the  Department  of  State  and  the 
0MB  for  review  and  comment  on  the  Resources  and  Tentative  Fiscal 
Guidance  sections  of  the  draft  DG. 

15.  By  mid-November,  the  various  comments  are  provided  to  the  OllSD- 
(P).  Again,  where  possible,  issues  raised  by  the  comments  are  re¬ 
solved  between  the  various  staffs  and  the  draft  DG  revised  as 
necessary.  Issues  requiring  ORB  review  and  resolution  are  identi¬ 
fied.  At  the  same  time,  the  OUSDRE  and  the  0ASD(MRA&L)  prepare 
briefings  on  the  resources  issues  of  the  draft  DG. 

16.  In  late  November,  the  DRB  meets  to  review  the  revised  draft  DG 
and,  the  various  comments  on  the  draft  DG  and  to  resolve  the  re¬ 
maining  issues  on  the  draft  DG.  The  DRB  is  also  briefed  on  the 
resource  implications  and  constraints  of  the  revised  draft  DG. 
This  review  and  briefing  provide  an  early  insight  into  areas  of 
strategic  capability  mismatches  and  risks, 

17.  In  late  November/early  December,  as  a  result  of  the  DRB  review  and 
briefing,  the  SECNAV  and  other  Service  Secretaries,  OSD  members  and 
the  JCS,  working  with  the  DRB  members,  are  tasked,  as  necessary,  by 
the  Deputy  SECDEF  (DEPSECDEF),  to  develop  proposed  alternative 
solutions  to  reduce  the  identified  risks. 

18.  In  early  December,  these  proposed  solutions  are  presented  to  the 
DRB.  As  a  result  of  this  review,  the  DRB  develops  its  recom¬ 
mendations  for  changes  to  the  revised  draft  DG. 

NOTE:  In  some  cases,  the  DRB  may  recommend  that  the  SECDEF  re¬ 

quest  an  increase  in  resources  to  reduce  the  mismatch  and 
risks. 
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PLANNING  PHASE  continued  (mid-December  1983  to  early  January  1984) 


19.  By  mid-December,  the  OJCS,  based  on  the  revised  draft  DG  and  the 
DRB  recommendations,  prepares  tables  of  expected  major  forces  which 
it  estimates  will  minimize  the  risks  involved  and  an  assessment  of 
the  risks  associated  with  their  ability  to  carry  out  the  strategy 
contained  In  the  DRB  recommendations. 

20.  In  mid-December,  the  DRB  decisions  on  major  Issues,  that  result  in 
changes  in  guidance  emphasis/force  mixes,  are  reflected,  by  the 
OUSD(P),  In  an  updated  draft  DG.  At  this  time,  the  OUSD(P)  also 
prepares  a  list  of  any  unresolved  problems  and/or  Issues. 

21.  At  the  end  of  December,  the  updated  draft  DG,  the  DRB  recommen¬ 
dations  as  to  mismatch  and  risks,  the  associated  OJCS  force  tables 
and  risk  assessment  and  any  unresolved  problems  and/or  Issues  are 
reviewed  and  resolved  by  the  SECDEF. 

22.  In  early  January,  based  on  the  updated  draft  DG  and  the  SECDEF 
decisions,  the  OUSD(P)  prepares  the  proposed  DG. 

23.  In  early  January,  the  proposed  DG  is  presented  to  the  SECDEF  for 
review  and  approval. 
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PROGRAMMING  PHASE  (January  1984  to  June  1984) 


24.  In  early  February,  based  on  the  DG,  the  CEB  recommendations  and  the 
CNC's  direction,  OPNAV  promulgates  the  CNO  Programing  and  Fiscal 
Guidance  (CPFG)  which  provides  guidance  for  the  development  of  the 
Navy  Program  Objectives  Memorandum  (POM). 

25.  In  March,  OPNAV  Sponsors  prepare,  based  on  the  CPFG,  and  present 
Sponsor  Program  Proposals  (SPPs)  and  program  assessments  to  the 
Program  Development  Review  Committee  (PDRC)  for  review  and  appro¬ 
val. 

26.  In  April,  based  on  the  SPPs  and  PDRC  recommendations,  OPNAV  pre¬ 
pares  the  Program  Evaluation  and  Decision  Summary  (PEDS)  which  is 
presented  first  to  the  CNO  and  CEB  and  then  to  SECNAV  for  review 
and  approval . 

27.  In  May,  OPNAV  and  the  SECNAV  Staff  prepare  the  Navy  POM  and  submit 
it  to  the  SECNAV  for  review  and  approval. 

28.  In  May,  copies  of  the  Navy  POM  and  the  POMs  of  the  other  DOD 
Components  are  provided  to  the  SECDEF,  the  DRB  members  and  the 
OJCS.  Based  on  Its  review  of  the  POMs,  the  OJCS  prepares  its  Joint 
Program  Assessment  Memorandum  (JPAM). 

29.  In  June,  the  JPAM  is  forwarded  to  the  DRB  members.  The  DRB  members' 
staffs,  after  review  of  the  POMs  and  the  JPAM,  Identify  any  issues 
raised  by  this  review.  As  many  issues  as  possible  are  resolved 
between  the  DRB  members'  staffs  and  the  DOD  Components  and  the 
OJCS.  Issues  which  cannot  be  resolved  are  documented  as  Issue 
Papers  for  insertion  into  the  Final  Issues  Book. 


PROGRAMMING  PHASE  continued  (June  1984  to  July  1984) 


30.  In  June,  copies  of  the  Final  Issues  Books  are  provided  to  the  DRB 
members  for  review  and  brief  executive-level  comments. 

31.  In  July,  the  DRB  comments  are  provided  to  the  DRB  Executive 
Secretary  for  Assembly  into  Issue  Books. 

32.  In  July,  the  Issue  Books  and  comments  are  provided  to  the  DRB  for 
review.  After  review,  the  DRB  determines  its  position  on  the  POMs. 
These  positions  are  recorded  in  a  set  of  Program  Decision  Memoranda 
(PDMs),  one  PDM  for  each  POM. 


BUDGETING  PHASE  (June  1982  to  early  December  1982) 


33.  In  June  and  July,  based  on  the  Navy  POM  and  guidance  from  the 
Deputy  Under  SECNAV  (Comptroller)  (DUSN(C)),  the  Navy  Claimants 
prepare  and  submit  their  proposed  budgets  to  the  DUSN(C).  Based  on 
these  submittals  and  any  late  appeal,  the  DUSN(C)  prepares  his 
recommendations.  The  POM,  PDM,  proposed  Claimant  budgets  and  the 
DUSN(C)  recommendations  and  resultant  SECNAV  decisions  form  the 
basis  for  the  Navy's  budget. 

34.  In  September,  the  proposed  budgets  of  the  DON  and  the  other  DOD 
Components  are  submitted  to  the  Assistant  Secretary  of  Defense 
(Comptroller)  (ASD(C)).  After  review,  the  ASD(C)  determines  his 
positions  on  the  proposed  budgets.  These  positions  are  recorded  in 
a  set  of  proposed  Program  Budget  Decisions  (PBDs),  one  for  each 
submitted  budget. 

35.  In  October  and  November,  the  proposed  PBDs  are  submitted  to  the 
DEPSECDEF  for  review  and  approval. 

36.  In  October  and  November,  copies  of  the  PBDs  are  also  supplied  to 
the  DON  and  other  DOD  Components.  After  review,  the  DON  and  other 
DOD  Components  prepare,  for  items  they  are  in  disagreement  with, 
appeal  issues. 

37.  In  November,  the  DON’S  and  other  DOD  Components'  appeal  issues 
are  presented  to  the  DRB  for  review  and  resolution. 

38.  In  mid-December,  the  SECNAV  and  CNO,  and  the  other  DOD  Components 
Secretaries  and  Service  Chiefs  meet  with  the  DRB  to  resolve  major 
budget  issues  (MBIs)  still  outstanding  and  of  sufficient  importance 
to  be  brought  directly  to  the  attention  of  the  SECDEF. 
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BUDGETING  PHASE  continued  (early  December  1984  to  January  1985) 


39.  In  early  December,  the  DRB  meets  to  review  the  SECDEF's  proposed 
budget  recommendations  which  he  plans  to  present  to  the  President. 
Based  on  that  review,  the  DRB  prepares  its  recommendations  to  the 
SECDEF. 

40.  In  mid-December,  the  DRB's  recommendations  are  submitted  to  the 

SECDEF.  The  SECDEF,  in  turn,  makes  his  reconmendati ons  to  the 

President  who,  after  review,  provides  the  SECDEF  with  his  final 
budget  guidance. 

41.  In  mid-December,  based  on  the  approved  PBDs,  the  DOD  Components' 
PBD  appeals  and  MBIs  resolutions  and  the  President's  final  budget 
guidance  provided  to  the  SECDEF,  the  DRB  meets  to  establish  the 
final  budget  guidance  for  the  DON  and  other  DOD  Components,  which 
is  transmitted  by  the  final  PBDs. 

42.  In  late  December,  the  DON  and  other  DOD  Components  prepare  their 
proposed  Final  Budgets  based  on  the  final  budget  guidance,  their 
earlier  submitted  proposed  budgets,  the  approved  PBDs  and  their  PBD 
appeal  issue  resolutions. 

43.  In  late  December,  the  DON  and  other  DOD  Components'  proposed  Final 
Budgets  are  forwarded  to  the  Office  of  the  ASD(C)  (OASD(C))  which 
combines  them  into  a  single  proposed  00D  Budget. 

44.  In  late  December/early  January,  the  proposed  Final  DOD  Budget  is 
submitted  to  the  SECDEF  for  review  and  approval.  The  DOD  Budget  is 
then  forwarded  to  Office  of  Management  and  Budget  (0MB)  where  it  is 
incorporated  into  a  single  National  Budget,  approved  by  the  Presi¬ 
dent  and  submitted  to  the  Congress,  in  January,  enactment. 
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Appendix  C 
ABBREVIATIONS 


A 


AAW 

ACAT 

AGO 

ACWP 

ADM 

ADPO 

AFP 

APPRO 

AFWTF 

ALP 

ALT 

AP 

APDM 

APM 

AR 

ARB 

ARC 

AS 

AS 

ASD 

ASD(C) 

ASD ( C3 I ) 

ASD(ISA) 

ASD(MRASL) 

ASN 

ASN(FM) 

ASN(MSRA) 

ASNIRE&S) 

ASN(SSL) 

ASP 

ASPJ 

ASU 

ASUW 

ASW 

AUTEC 

ATM 


Anti -Air  Warfare 
Acquisition  Category 
Administrative  Contracting  Officer 
Actual  Cost  of  Work  Performed 
Advanced  Development  Model 
Advanced  Development  Project  Office 
Approved  (approval)  for  Full  Production 
Air  Force  Plant  Representative  Office 
Atlantic  Fleet  Weapons  Training  Facility 
Approved  (approval)  for  Limited  Production 
Administrative  Lead  Time 
Acquisition  Plan 

Approved  Program  Decision  Memorandum 

Assistant  Program  Manager 

(Nav)Air  Regulation 

Acquisition  Review  Board 

Acquisition  Review  Committee 

Aerospace  Standard 

NAV(AIR)  Specification 

Assistant  Secretary  of  Defense 

Assistant  Secretary  of  Defense  (Comptroller) 

Assistant  Secretary  of  Defense  (Command,  Control,  Com¬ 
munication  and  Intelligence 

Assistant  Secretary  of  Defense  (International  Security 
Affairs) 

Assistant  Secretary  of  Defense  (Manpower,  Reserve  Affai 
and  Logistics) 

Assistant  Secretary  of  the  Navy 

Assistant  Secretary  of  the  Navy  (Financial  Management) 
Assistant  Secretary  of  the  Navy  (Manpower  and  Reserve 
Affairs) 

Assistant  Secretary  of  the  Navy  (Research,  Engineering 
and  Systems) 

Assistant  Secretary  of  the  Navy  (Shipbuilding  and  Logis 
tics) 

Acquisition  Strategy  Plan 

Advanced  Self-Protection  Jammer 

Approval  for  Service  Use  (replaced  with  AFP) 

Anti -Surface  Warfare 
Antisubmarine  Warfare 

Atlantic  Underseas  Test  and  Evaluation  Center 
Assistant  Technical  Manager 


B 

BCE  Baseline  Cost  Estimate 

BCWP  Budgeted  Cost  of  Work  Performed 


-B- 

(continued) 


BCWS 

Budgeted  Cost  of  Work  Scheduled 

B*S 

Board  of  Inspection  and  Survey 

¥ 

BM 

Business  Manager 

BUL 

Bulletin 

CA 

Commercial  Activities 

CAIG 

Cost  Analysis  Improvement  Group 

'V 

CBD 

Commerce  Business  Daily 

", 

CBR 

Chemical,  Biological,  Radiological 

CCB 

Change  Control  Board 

u:  .•  J 

CDR 

Critical  Design  Review 

ft. 

CDRL 

Contract  Data  Requirements  List 

CE 

Concept  Exploration  (Phase) 

CEB 

CNO  Executive  Board 

CICA 

Competition  in  Contracting  Act  of  1984 

CINC 

Commander-in-Chief 

to  1  •*< 

CJCS 

Chairman,  Joint  Chiefs  of  Staff 

ft 

CMC 

Commander,  Marine  Corps 

CNET 

Chief,  Naval  Education  and  Training 

CNM 

Chief  of  Naval  Material 

CNO 

Chief  of  Naval  Operations 

CO 

Contracting  Officer 

to*  -'-i 

COMOPTEVFOR 

Commander,  Operational  Test  and  Evaluation  Force 

ft 

CPAF 

Cost  Plus  Award  Fee 

CPAM 

CNO  Program  Analysis  Memorandum 

CPFF 

Cost  Plus  Fixed  Fee 

CPFG 

CNO  Program  and  Fiscal  Guidance 

CPIF 

Cost  Plus  Incentive  Fee 

CPM 

Critical  Path  Method 

ft 

CPPG 

CNO  Planning  and  Programming  Guidance 

CRDL 

Contract  Data  Requirements  List 

CS 

Cost  Sharing 

v 

C/SCS 

Cost/Schedule  Control  System 

y 

CSS 

Cost  Support  Services 

vv 

CTR 

Center 

• 

DA 

D 

Development  Activity 

DADM 

Decision  Authority  Decision  Memorandum 

• 

DAES 

Defense  Acquisition  Executive  Summary 

D&F 

Determination  and  Findings 

D&V 

Demonstration  and  Validation 

v  .■ 

DC 

Development  Coordinator 

DCAS 

Defense  Contract  Administration  Service 

DCASR 

Defense  Contract  Administration  Service  Representative/ 

Region 

# 

DCNM 

Deputy  Chief  of  Naval  Material 

C-? 

N; 

-D- 

(continued) 


DCNM(A) 
DCNM(C&BM) 
DCNM(L) 
DCNM(R&M)  ■ 
DCNM(RMSQA) 

DC  NO 

DCNQ(MP&T) 

DCN0(PP&0) 

DCP 

DCR 

DDT&E 

DEPSECDEF 

DFARDS 

OG 

DID 

DLA 

DMSO 

DNA 

DNPP 

DNSARC 

DOD 

DODD 

DODI 

DON 

DONPIC 

DOP 

D( PA&E ) 

DPM 

DRB 

DRRB 

DSARC 

DSD 

DSMC 

DT 

DTC 

DT&E 

DTNSRDC 

DUSD(PR) 

DUSN(FM) 


Deputy  CNM  (Acquisition) 

Deputy  CNM  (Contracts  and  Business  Management) 

Deputy  CNM  (Logistics) 

Deputy  CNM  (Reliability  and  Maintainability) 

Deputy  CNM  (Reliability,  Maintainability  and  Quality 
Assurance) 

Deputy  Chief  of  Naval  Operations 

Deputy  Chief  of  Naval  Operations  (Manpower,  Personnel  and 
Training) 

Deputy  Chief  of  Naval  Operations  (Plans,  Policy  and 
Operations) 

Decision  Coordinating  Paper 

Design  Certification  Review 

Director,  Defense  Test  and  Evaluation 

Deputy  Secretary  of  Defense 

DOD  Federal  Acquisition  Regulation  Supplement 

Defense  Guidance 

Data  Item  Description 

Defense  Logistics  Agency 

Director,  Major  Staff  Office 

Defense  Nuclear  Agency 

Director  of  Navy  Plans  and  Programs 

Department  of  the  Navy  System  Acquisition  Review  Council 

Department  of  Defense 

Department  of  Defense  Directive 

Department  of  Defense  Instruction 

Department  of  the  Navy 

DON  Program  Information  Center 

Development  Options  Paper 

Director,  Program  Analysis  and  Evaluation 

Deputy  Program  Manager 

Defense  Resources  Board 

Data  Requirements  Review  Board 

Defense  Systems  Acquisition  Review  Council 

Deputy  Secretary  of  Defense 

Defense  Systems  Management  College 

Development  Test 

Design-To-Cost 

Development  Test  and  Evaluation 
David  W.  Taylor  Naval  Ship  Research  and  Development 
Center 

Deputy  Under  Secretary  of  Defense  for  Policy  Review 
Deputy  Under  Secretary  of  the  Navy,  Financial  Management 


E 


EAC 

ECP 

ECCM 

ECM 

ECR 


Estimated  Cost  at  Completion 
Engineering  Change  Proposal 
Electronic  Counter-Countermeasures 
Electronic  Countermeasures 
Embedded  Computer  Resource 
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EDCD 

EDM 

EMC 

EMI 

EMP 

EMSP 

EPA 

ESM 

EPR 


FAC  I 

FAI 

FAR 

FAT 

FCA 

FCRC 

FFP 

FIP 

FMP 

FMS 

FOM 

FOT&E 

FPEA 

FPIF 

FPR 

FPIS 

FSD 

FTTS 

FYDP 


G&A 

GAT 

GFE 

GFI 

GFM 


HARDMAN 

HDBK 

HEL 

HLT 

HME 

HQMC 


Environmental  Design  Criteria  Document 
Engineering  Development  Model 
Electromagnetic  Compatibility 
Electromagnetic  Interference 
Electromagnetic  Pulse 
Enhanced  Modular  Signal  Processor 
Extended  Planning  Annex 
Electronic  Support  Measure 
Environmental  Profile  Report 


F 

First-Article  Configuration  Inspection 
Federal  Acquisition  Institute 
Federal  Acquisition  Regulation 
Factory  Acceptance  Test 
Functional  Configuration  Audit 
Federal  Contract  Research  Center 
Firm  Fixed  Price 
Functional  Implementation  Plan 
Fleet  Modernization  Program 
Foreign  Military  Sales 
Figure  of  Merit 

Follow-on  Operational  Test  and  Evaluation 
Fixed-Price  with  Economic  Adjustment 
Fixed-Price  Incentive  Fee 
Fixed-Price  Redetermination 
Fixed-Price  Incentive,  Successive  Targets 
Full-Scale  Development  (Phase) 
Factory-To-Target  Sequence 
Five-Year  Defense  Program 


G 

General  and  Administrative 
Government  Acceptance  Test 
Government-Furnished  Equipment 
Government-Furnished  Information 
Government-Furnished  Material 


H 


Hardware  Manpower 
Handbook 

High-Energy  Laser 
Hardware  Lead  Time 
Hull,  Mechanical  and  Llectrical 
Headquarters,  Marine  Corps 
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I 


ILS 

ILSP 

IMET 

IOC 

IOT&E 

I  PR 

IPS 

IR 

IR&O 


Integrated  Logistics  Support 

Integrated  Logistics  Support  Plan 

International  Military  Education  and  Training 

Initial  Operational  Capability 

Initial  Operational  Test  and  Evaluation 

In-Progress  Review 

Integrated  Program  Summary 

Infrared 

Independent  Research  and  Development 


J 


JCS 

JMSNS 

JPAM 

JSPD 

JT&E 


Joint  Chiefs  of  Staff 
Justification  for  Major  System  New  Start 
Joint  Program  Assessment  Memorandum 
Joint  Strategic  Planning  Document 
Joint  Service  Test  and  Evaluation 


L 


LCC 

LLTP 

LM 

LMTC 

LOE 

LORA 

LP 

LRG 

LSA 


Life-Cycle  Cost 

Long  Lead  Time  Procurement 

Logistics  Manager 

Logistics  Management  Training  Center 

Level  Of  Effort 

Level  Of  Repair  Analysis 

Life  Profile 

Logistics  Review  Group 

Logistics  Support  Analysis 


M 


MASM 

MCDEC 

MCO 

MCORD 

MCOTEA 

MDCS 

MEWS 

MILCON 

MIP 

MIS 

MMMS 

MND 

MOA 

MOU 

MP 

MPM 

MPS 

MP&TS 


Military  Assistance  and  Sales  Manual 
Marine  Corps  Development  and  Education  Center 
Marine  Corps  Order 
Marine  Corps  Order 

Marine  Corps  Operational  Test  and  Evaluation  Agency 

Maintenance  Data  Collection  System 

Minimum  Essential  Weapon  System 

Military  Construction 

Navy  RDT&E  Management  Information  Paper 

Mission  Information  System 

Maintenance  and  Material  Management  System  (3M  System) 

Mission  Need  Determination 

Memorandum  Of  Agreement 

Memorandum  Of  Understanding 

Mission  Profile 

Milestone  Planning  Meeting 

Merit  Pay  System 
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Organization  of  the  Joint  Chiefs  of  Staff 

Office  of  Management  and  Budget 
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Office  of  the  Secretary  of  Defense 
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P3I  (PPPI) 

PAT&E 

PBD 

PC 

PCA 

PCO 

PDA 

PDM 

PDR 

PDS 

PERT 

PHST 

PIP 
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PM 

PMO 

PMP 

PMT 

PMTC 

POM 

PPBS 

PPM 

PRDR 

PRESINSURV 

PRO 

PSD 

PSO 


Preplanned  Product  Improvement 

Production  Acceptance  Test  and  Evaluation 

Program  Budgeting  Decision 

Program  Coordinator 

Physical  Configuration  Audit 

Procuring  Contracting  Officer 

Program  Decision  Authority 

Program  Decision  Memorandum 

Preliminary  Design  Review 

Program  Decision  Set 

Program  Evaluation  and  Review  Technique 

Packaging,  Handling,  Storage,  Transportation 

Product  Improvement  Program 
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Program  Manager 

Program  Management  Office  or  Organization 

Program  Management  Proposal 
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Preproduction  Reliability  Design  Review 

President  of  the  Board  of  Inspection  and  Survey 
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Program  Support  Office 
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QA  Quality  Assurance 

QC  Quality  Control 
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Resource  Allocation  Display 
Request  for  Authority  to  Negotiate 
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;  rcs 

Radar  Cross  Section 

|  R&D 

Research  and  Development 

► 

RDT&E 

Research,  Development,  Test  and  Evaluation 

RD 

Requirement  Document 

[  RFP 

Request  For  Proposal 

!•  RFQ 

Request  For  Quotation 

L  R&M 

Reliability  and  Maintainability 

1  RM&A 

Reliability,  Maintainability,  and  Availability 

> 

;•  ROC 

Required  Operational  Capability 

1  RPV 

Remotely  Piloted  Vehicle 

\  RSI 

y 

'y- 

r 

Rationalization,  Standardization  and  Interoperability 

1 

SAR 

S 

Selected  Acquisition  Report 

> 

SCIB 

Ship  Characteristics  and  Improvement  Board 

:  scp 

System  Concept  Paper 

,■  SDDM 

SECDEF  Decision  Memorandum 

i  SECDEF 

Secretary  of  Defense 

1 

SECNAV 

Secretary  of  the  Navy 

SEM 

Standard  Eauipment  Module 

:  SEMP 

System  Engineering  Management  Program 

SES 

Senior  Executive  Service 

,  SMI 

Ship  Manpower  Information 

1  SMD 

Ship  Manpower  Document 

t 

SNDM 

SECNAV  Decision  Memorandum 

-  SOW 

Statement  Of  Work 

:  SPP 

Sponsor  Program  Proposal 

-  SQMD 

Squadron  Manpower  Document 

SSA 

Source  Selection  Authority 

SSC 

Source  Selection  Council 

» 

SSEB 

Source  Selection  Evaluation  Board 

“■ 

SSPK 

Single-Shot  Probability  of  Kill 

SSPO 

Strategic  Systems  Project  Office 

SSPP 

System  Safety  Program  Plan 

SUP 

Service-Use- Profile 

SYSCOM 

Systems  Command 

» 

TAAF 

T 

Test,  Analyze,  and  Fix 

!  TADSTAND 

Tactical  Digital  Standards 

1 

TDP 

Technical  Data  Package 

T&E 

Test  and  Evaluation 

TECHEVAL 

TECPO 

Technical  Evaluation 

Tactical  Embedded  Computer  Program  Office 

*.-/ 

TEMP 

Test  and  Evaluation  Master  Plan 

TM 

Technical  Manager 

1 

TOR 

Tentative  Operational  Requirement 

TPS 

Tentative  Program  Summary 
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USD(P) 

USD(RSE) 

USDR&E 
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WSESRB 
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Work  Breakdown  Structure 

Weapons  Systems  Explosive  Safety  Review  Board 

Weapons  System  Improvement  Group 
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